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Executive  Summary 


The  Software  Engineering  Institute  (SEI)  facilitated  a  two-day  Technology  Adoption 
Planning  workshop  for  the  SSG  Transformation  Team  (vice  director  and  the  directors  of  the 
2-letter  organizations)  on  October  27  and  28,  2003  at  the  Alabama  TechnaCenter  in 
Montgomery,  Alabama.  The  workshop  was  also  attended  by  SSG  personnel  who  were 
responsible  for  partnering  with  the  SEI  on  the  tasks  in  the  FY03-04  SEI/SSG  work  plan. 

The  purpose  of  the  workshop  was  to  initiate  the  planning  for  phase  2  of  the  SSG/SEI 
partnership.  (Phase  1,  the  “Enterprise  Assessment,”  was  conducted  in  Jan  03  and  an  out  brief 
was  delivered  in  May  03).  The  workshop  focused  on  producing  a  tactical  plan  for 
incorporating  the  recommended  SEI  technical  solutions  (based  on  SSG-expressed  needs 
during  Phase  1)  into  the  ongoing  SSG  transformation  activities. 


Workshop  participants  began  by  reviewing  the  SSG  FY03-08  Strategic  Objectives  and  the 
Balanced  Score  Card  (BSC)  objectives  to  verify  that  they  were  still  relevant  and  supportive 
of  the  SSG  Strategic  Goals.  After  reviewing  the  list  of  21  objectives,  the  SSG 
Transformation  Team  confirmed  that  all  of  the  objectives  are  still  relevant,  although  it  was 
noted  that  a  few  of  them  could  be  consolidated. 


The  objectives  were  grouped  into  three  categories  (customer  focused,  internal  operations,  and 
innovation  &  learning).  During  the  remainder  of  the  workshop,  SSG  personnel  participated 
in  group  activities  where  key  technical  challenges  facing  SSG  were  identified.  SEI  personnel 
identified  those  where  SEI  could  provide  expertise/support.  A  mapping  exercise  of  SSG 
needs  to  SEI  expertise  was  conducted.  SSG  personnel  then  “dot  voted”  on  the  top  three  areas 
they  thought  were  the  most  important  for  SSG  to  pursue  in  the  near  term.  The  top  three  are 
COTS-Based  Systems  (CBS)  support/integration,  People -CMM  (P-CMM)  support,  and 
Process  Improvement  support.  Interested  SSG  2-letter  organizations  were  identified  as 
partners  for  each  task  and  then  individuals  from  these  organizations  volunteered  to  be  the 
primary  POC.  They  are: 

•  COTS  systems  support/integration  -  Steve  Wright  (EN) 

•  P-CMM  -  Lt  Col  Ingenloff  (DP) 

•  Process  Improvement  -  Tom  Speakman  (XPJ) 

Next  step  is  for  the  SEI  to  draft  another  version  of  the  FY04  work  plan  with  more  detailed 
task  descriptions  including  specific  deliverables,  a  schedule,  and  a  revised  cost  estimate. 
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Abstract 


The  Software  Engineering  Institute  (SEI)  facilitated  a  two-day  Technology  Adoption 
Planning  workshop  for  the  Standard  Systems  Group  (SSG)  Transformation  Team  (Vice 
Director  and  the  Directors  of  the  2-letter  organizations)  on  October  27  and  28,  2003  at  the 
Alabama  TechnaCenter  in  Montgomery,  Alabama.  Other  pertinent  SSG  personnel,  with 
responsibility  for  partnering  with  the  SEI  on  the  tasks  in  the  FY03-04  SEI/SSG  work  plan, 
also  were  invited  and  attended. 


The  purpose  of  the  workshop  was  to  initiate  the  planning  for  phase  2  of  the  SSG/SEI 
partnership.  (Phase  1  was  the  “Enterprise  Assessment”  conducted  in  January  2003  and  out 
briefed  in  May  03).  The  workshop  was  focused  on  producing  a  tactical  plan  for 
incorporating  the  recommended  SEI  technical  solutions  (based  on  SSG-expressed  needs 
during  Phase  1)  into  the  ongoing  SSG  transformation  activities. 
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1  Organization  of  This  Report 


This  report  is  organized  into  the  following  sections: 

Background:  This  section  provides  information  as  to  why  the  workshop  was  held  and  other 
relevant  background  information  expected  to  be  needed  to  understand  the  workshop  report. 

Workshop  Purpose:  This  section  elaborates  on  the  purpose  of  holding  the  workshop. 

Workshop  Goals/Desired  Outcomes:  This  section  elaborates  on  the  deliverables  of  the 
workshop  and  provides  details  on  the  goals  that  supported  the  puipose  of  the  workshop. 

Participants:  This  section  describes  the  SSG  and  the  SEI  participants  of  the  workshop. 

Workshop  Approach:  This  section  describes  the  rationale  for  the  workshop  activities  and 
agenda  items. 

Nominal  Agenda:  This  section  contains  the  planned  agenda  for  the  workshop  as  well  as  the 
actual  agenda  that  was  followed. 

Agenda  Items  Summary:  This  section  outlines  the  desired  outcomes,  results  summary,  and 
discussion  of  each  agenda  item. 

Appendices  A  -  N:  The  appendices  at  the  end  of  this  report  contain  the  raw  data  produced  in 
the  workshop  (such  as  flip  charts  and  other  notes)  as  well  as  artifacts  from  the  workshops 
(such  as  background  information  and  presentations  used  during  the  workshop). 
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2  Background 


In  late  CY02,  the  SEI  was  asked  by  the  new  SSG  director,  Mr.  Frank  Weber,  to  perform  an 
“enterprise  assessment”  of  SSG.  SSG’s  goal  is  to  establish  itself  as  a  Center  of  Excellence 
(CoE)  for  Air  Force  combat  support  Information  technology  (IT)  systems.  Given  that  goal, 
SSG  asked  the  SEI  to  provide  initial,  objective  insights  on  core  SSG  processes/organizations 
that  are  critical  to  establishing  this  CoE,  to  include: 

•  Roles/relationships  between  the  Program  Offices  and  Software  Factory. 

•  Skills  mix  required  to  support  future  AF  IT  environment,  to  include  best  balance  of  blue 
suit  vs.  government  civilian  vs.  contractors,  considering  legacy  system  requirements, 
modernization/technology  evolution  and  training  requirements/capabilities. 

•  Core  competencies  to  promote  an  integrated  combat  support  system  domain. 

•  Basic  organizational  strategies. 

Initial  work  culminated  in  a  17  Jan  03  briefing,  which  addressed  areas  of  Apparent  Strength 
and  Areas  of  Apparent  Concern  toward  the  accomplishment  of  this  goal. 

Further  investigation  to  include  interviews  and  discussions  with  various  Air  Force  leaders 
resulted  in  a  more  detailed  presentation  and  a  closeout  of  the  “discovery  phase”  on  8  May  03. 

The  tasking  in  this  work  plan  is  the  direct  result  of  the  aforementioned  assessment  outbriefs 
and  ongoing  discussion/direction  from  SSG  leadership  and  is  meant  to  be  consistent  with  Mr. 
Weber’s  stated  goals: 

•  Make  SSG  Easy  to  do  business  with  ...  as  deemed  by  our  customers! 

•  Streamlined  organization  with  agile  processes 

•  Recognized  expertise  in  exploring  and  exploiting  leading  IT  technologies 

•  Enterprise-wide  perspective 

The  Technology  Adoption  Planning  workshop  was  part  of  the  tasking  statement  of  SEI’s 
Fiscal  Year  2003-04  Work  Plan  for  the  Standard  Systems  Group.  This  workshop  was 
specifically  focused  on  producing  a  working  plan  for  incorporating  technologies  in  the  SEI 
work  plan  into  the  SSG  transformation  activities.  The  workshop  began  by  reviewing  the 
objectives  and  achievement  strategies  in  the  SSG  FY03-08  Strategic  Plan  dated  August  22, 
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2002  to  validate  that  they  are  still  relevant  in  the  context  of  recent  organizational  changes  and 
priority  changes.  Working  with  the  SSG  leadership  team,  the  SEI  collaborated  in  planning 
and  prioritizing  the  adoption  of  the  technologies  proposed  in  the  FY03-04  work  plan.  These 
will  be  explicitly  connected  to  the  SSG  strategic  objectives  in  order  to  provide  maximum 
benefit  to  SSG  in  achieving  said  objectives. 


The  SEI  worked  with  SSG  prior  to  the  workshop  to  establish  the  agenda  and  identify 
appropriate  participants.  Attendees  at  the  workshop  included  the  Vice  Director  of  SSG,  his 
direct  reports,  and  staff  members  who  will  be  responsible  for  implementing,  monitoring,  and 
controlling  the  transformation  effort. 


4 


CMU/SEI-2004-SR-003 


3  Workshop  Purpose 


The  purpose  of  the  SSG  Technology  Adoption  Planning  Workshop  was  to  come  up  with  a 
prioritized  list  of  SSG’s  strategic  objectives  tied  to  specific  tasks  in  the  SEI  work  plan.  In 
addition  to  creating  the  prioritized  list  of  tasks,  sequencing  (i.e.,  education/training, 
consulting,  etc.)  of  the  subtasks  were  to  be  discussed  and  documented. 


A  technology  adoption  workshop  approach  was  considered  an  appropriate  method  to  come  up 
with  the  primary  list  of  activities.  In  addition,  the  workshop  helped  to  facilitate 
communication  among  and  between  the  SSG’s  departments  involved  in  the  two-day  event. 
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4  Workshop  Goals  and  Desired  Outcomes 


The  goals  of  the  workshop  included  the  following: 

•  Provide  a  communication  forum  between  SSG  and  the  SEI 

•  Establish  a  common  understanding  between  SEI  and  SSG’s  objectives/plan 

•  Establish  a  common  understanding  of  SEI’s  portfolio  of  “SSG  appropriate”  products 

•  Create  a  map  of  SEI  technologies  showing  explicit  connections  to  various  SSG  strategic 
objectives 

The  desired  outcomes  (deliverables)  from  the  workshop  included  the  following: 

•  A  prioritized  list  of  SSG’s  strategic  objectives  tied  to  specific  tasks  in  the  SEI  work  plan 

•  Sequencing  of  the  subtasks  discussed  and  documented 

•  Set  of  steps  and  dates  with  SEI  and  SSG  resources 

•  Workshop  report  (this  document) 
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5  Participants 


Participants  for  this  workshop  came  from  the  SEI  and  from  SSG.  The  SEI  provided 
facilitators  and  subject  matter  experts  for  the  workshop. 

The  following  list  includes  SEI  staff  members  and  their  respective  roles  in  the  workshop: 

•  Grady  Campbell,  Enterprise  Architecture  lead 

•  John  Foreman,  COTS-Based  Systems  lead 

•  Suzanne  Garcia,  Facilitator 

•  Kristi  Keeler,  Capability  Maturity  Model  Integration  (CMMI)  lead 

•  Lisa  Masciantonio,  Business  Manager 

•  Lorraine  Nemeth,  Facilitator 

•  Daniel  Plakosh,  Software  Sustainment  and  Modernizing  Legacy  Systems  leads 

•  Jan  Vargas,  SEI  tech  lead 

•  Gian  Wemyss,  People  Capability  Maturity  Model  (P-CMM)  lead 

The  following  table  lists  the  Standard  Systems  Group  participants  involved  in  the  workshop: 


Name 

Area  Represented 

Col  Dave  McKinney 

AQ 

Stephen  Stewart 

BI 

LtCol  Peter  Ingenloff 

DP/DAG 

CMSGT  Thomas  Kirksey 

EDX  (DAG) 

Willie  Miller 

DP/CCQ 

Kenneth  Heitkamp 

EA 

Eugene  Wright 

EN 

Col  Victor  Jevsevar 

EV 

John  Lucas 

FM 

Tommy  Pope 

Roger  Herndon 

FN 
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Diane  Suchan 

ILS 

Maj  John  Hartsell 

JA 

Maj  Pat  Reader 

MI 

Tom  Bayless 

PI 

Trish  Meadows 

SEPG  Lead 

David  Boulian 

ST 

Col  John  Courtney 

Col.  Larry  Wilson 

XO 

John  Macker 

XP 

Bloise  Stubblefield 

XP 

Richard  Plaskett 

XP  "Contractor” 

Jim  Hoffman 

XPHC 

Harold  Speakman 

XPJ 

Table  1:  Standard  Systems  Group  Participants  Involved  in  the  Workshop 


10 


CMU/SEI-2004-SR-003 


6  Workshop  Approach 


The  facilitators  of  this  workshop  utilized  agenda  items  and  activities  that  created  a  flow  of 
information  for  shared  understanding  among  all  participants,  as  well  as  allowing  a  forum  for 
open  communications.  The  following  diagram  depicts  the  flow  of  the  workshop. 


Info  sharing 


Mapping  between  SEI 
offers  &  SSG  needs 


Prioritization 


Risk  analysis 


Near  term 
planning 


Figure  1:  SSG  Workshop  Approach 
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7  Agendas 


The  planned  agendas  shown  in  Table  2  and  Table  3  were  created  and  sent  to  all  workshop 
attendees  before  the  workshop.  The  actual  agendas  shown  in  Table  4  and  Table  5  were 
revised  throughout  the  workshop  to  meet  the  changing  needs  of  the  workshop  and  evolved 
into  the  “Worked  Agendas.” 


The  actual  agendas  in  Table  4  and  Table  5  were  created  during  the  workshop  on  October  27 
and  28,  2003.  The  workshop  facilitators  worked  with  the  actual  agenda  and  fine-tuned  it  as 
each  day  progressed  to  meet  the  needs  of  the  audience. 
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Table  2:  Planned  Agenda  for  October  27,  2003 


October  27,  2003 

Time  Agenda  Topic  Lead/Participants  Desired  Outcome 

8:00  -  8:15  am 

Welcome  &  Why  the  SEI  is 

here 

Jevsevar 

Common  understanding  among  all 

participants. 

8:15-9:15  am 

Introductions 

Garcia  &  Nemeth  / 

All 

Each  participant  has  an  opportunity  to 

introduce  themselves,  and  state  their 

“wants/offers.” 

9:15-9:45  am 

Review/Agree  on  Workshop 

Objectives 

Garcia  &  Nemeth  / 

All 

Agreement  on  agenda  and  understanding  of 

objectives. 

9:45  -  10:00  am 

Break 

All 

Refresh. 

10:00-11:45  am 

Gunter  to  provide  review  of 

SSG’s  Strategic  Objectives 

Rick  Plaskett 

Common  understanding  of  SSG’s 

objectives/plan. 

11:45  am-  1:00 

pm 

Lunch 

All 

1:00  -  3:00  pm 

Review  SEI  Work 

Plan/Connect  to  SSG 

Objectives 

SEI  Tech  Leads 

Common  understanding  on  how  SEI’s 

ideas  map  to  SSG’s  objectives. 

1 :00  -  1 :05  pm 

Overview  of  Workplan 

Ian  Vargas 

1:05-  1:20  pm 

People  Capability  Maturity 

Model  (P-CMM) 

Gian  Wemyss 

1:20  -  1:35  pm 

Software  Sustainment 

Dan  Plakosh 

1:35  -  1:50  pm 

Modernizing  Legacy  Systems 

Dan  Plakosh 

1:50  -  2:05  pm 

Portfolio  Management  and 

Integration 

Dan  Plakosh 

2:05  -  2:  20  pm 

CMMI 

Kristi  Keeler 

2:20  -  2:35  pm 

COTS-Based  Systems 

lohn  Foreman 

2:35  -  2:50  pm 

Enterprise  Architecture 

Grady  Campbell 

2:50  -  3:00  pm 

(over  run  time) 

3:00  -  3:30  pm 

Break 

All 

Refresh. 

3:30  -  4:30  pm 

Create  map  of  Objectives/SEI 

connections 

Garcia  /  All 

Map  of  SEI  technologies  showing  explicit 

connections  to  various  SSG  strategic 

objectives. 

4:30  pm 

Adjourn 
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Table  3:  Planned  Agenda  for  October  28,  2003 


October  28,  2003 

Note:  To  accommodate  the  needs  of  SSG,  this  agenda  was  modified  based  on  the  results  of  the  October  27  agenda. 

Time  Agenda  Topic  Lead/Participants  Desired  Outcome 

8:00  -  8:30  am 

Review  Day  1  Work;  Revise 

as  Necessary 

Garcia  &  Nemeth  / 

All 

Reset  on  where  we  are. 

8:30  -  10:00  am 

Prioritize  SEI  Work  Plan 

Tasks 

Garcia  &  Nemeth  / 

All 

SEI's  tasks  in  prioritized  order. 

10:00-10:15  am 

Break 

All 

Refresh. 

10:15 -11:45  am 

Perform  Readiness/Fit 

Analysis  for  Top  3  Tasks 

Garcia  &  Nemeth  / 

All 

Transition  risk  list  related  to  top  three  SEI 

tasks  and  transition  risk  profiles. 

11:45  am-  1:00 

pm 

Lunch 

All 

1:00  -  3:00  pm 

Next  Steps 

Garcia  &  Nemeth  / 

All 

Set  of  steps  with  dates  with  SEI  and  SSG 

resources. 

3:00  -  3:30  pm 

Evaluate  "Want”  Satisfaction 

Nemeth  /  All 

Understanding  of  what's  been  done  and 

what  needs  to  be  done. 

3:30  pm 

Concluding  Remarks  and 

Adjourn 

Jevsevar 
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Table  4:  Actual  Agenda  for  October  27,  2003 


October  27 

Time 

Agenda  Topic 

Lead/Participants 

Desired  Outcome 

8:00  -  8:15  am 

Welcome  &  Why  the  SEI  is 

here 

Jevsevar 

Common  understanding  among  all 

participants. 

8:15  -  8:30  am 

Introductions 

Garcia  &  Nemeth  / 

All 

Each  participant  has  an  opportunity  to 

introduce  themselves,  and  state  their 

“wants/offers.” 

8:30  -  8:45  am 

Review/Agree  on  Workshop 

Objectives 

Garcia  &  Nemeth  / 

All 

Agreement  on  agenda  and  understanding 

of  objectives. 

8:45  -  10:40  am 

Gunter  to  provide  review  of 

SSG’s  Strategic  Objectives 

Rick  Plaskett 

Common  understanding  of  SSG’s 

objectives/plan. 

(9:20-9:45) 

Break 

All 

Refresh 

10:40  -  10:45  am 

Overview  of  Workplan 

Jan  Vargas 

10:45-11:10 

People  Capability  Maturity 

Model  (P-CMM) 

Gian  Wemyss 

11:10-11:35  am 

Enterprise  Architecture 

Grady  Campbell 

(1 1:35  am-l:00  pm) 

Lunch 

All 

1:00-1:25 

Software  Sustainment 

Dan  Plakosh 

1:25  -  2:00  pm 

Modernizing  Legacy  Systems 

Dan  Plakosh 

2:42-3:07  pm 

COTS-Based  Systems 

John  Foreman 

(3:07-3:30  pm) 

Break 

All 

3:30-4:30  pm 

Create  map  of  objectives/SEI 

connections 

Garcia/ All 

Map  of  SEI  technologies  showing  explicit 

connections  to  various  SSG  strategic 

objectives. 

4:30  pm 

Adjourn 
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Table  5:  Actual  Agenda  for  October  28,  2003 


October  28,  2003 

Note:  To  accommodate  the  needs  of  SSG.  this  agenda  was  modified  based  on  the  results  of  the  October  27  agenda. 

Time 

Agenda  Topic 

Lead/Participants 

Desired  Outcome 

8:00  -  8:05  am 

Review  Day  1  Work;  Revise 

as  Necessary 

Garcia  &  Nemeth  / 

All 

Reset  on  where  we  are 

8:05  -  9:00  am 

Prioritize  SEI  Work  Plan 

Tasks 

Garcia  &  Nemeth  / 

All 

SEI's  tasks  in  prioritized  order 

9:00-  10:30  am 

Perform  Readiness/Fit 

Analysis  for  Top  3  Tasks 

All 

Transition  risk  list  related  to  top  three  SEI 

tasks  and  transition  risk  profiles 

-l-Break 

Refresh. 

10:30-  10:50  am 

Engagement  for  pilots  task 

planning 

Garcia  &  Nemeth  / 

All 

10:50-  11:05  am 

Close  up  main  part  of 

workshop 

-  Evaluate  meeting  (+  and 

delta) 

-  Folks  not  directly  involved 

in  the  Pilot  Tasks  may  leave 

Garcia  &  Nemeth  / 

All 

Is  there  anything  you  liked  about  this 

workshop?  Is  there  anything  the  SEI  can 

improve  upon? 

11:05  am-  12:30 

Lunch 

All 

pm 

12:30 -3:00  pm 

Task  planning 

All 

7.1.1  Rationale  for  Agenda  Changes 

The  major  changes  to  the  planned  agenda  and  the  actual  agenda  on  day  one  were  based  on  the 
fact  that  the  workshop  members  worked  through  the  morning  section  of  the  agenda  faster 
than  anticipated.  The  facilitators  also  allowed  an  hour  and  a  half  for  lunch,  as  participants 
had  a  distance  to  drive  to  eating  establishments.  The  schedule  was  shifted  slightly  during  the 
“Review  of  SEI  Work  Plan/Connect  to  SSG  Objectives”  to  accommodate  the  time  needs  of 
the  attendees  to  discuss  in  more  depth  some  of  the  topics  covered  by  the  SEI’s  subject  matter 
experts. 
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The  major  changes  to  the  workshop’s  agenda  during  day  two  included  the  workshop 
participants  working  through  the  morning’s  portions  more  rapidly  than  predicted.  The 
morning’s  sections  afforded  the  attendees  an  opportunity  to  evaluate  the  meeting.  The 
facilitators  closed  up  the  main  part  of  the  workshop  so  that  attendees  who  were  not  directly 
involved  in  the  Pilot  Tasks  could  leave.  Lunch  was  moved  up  earlier  to  leave  a  full  two  and  a 
half  hours  to  discuss  Task  Planning. 
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8  Agenda  Items  for  Day  1 ,  October  27, 
2003 


8.1  Welcome  and  why  the  SEI  is  here 

The  first  topic  on  the  agenda  for  day  one  was  a  welcoming  message  from  SEI’s  facilitators 
and  a  welcome  and  brief  talk  on  why  the  SEI  was  there  by  Col  Jevsevar. 


8.1.1  Desired  Outcomes 

Col  Jevsevar  wanted  all  of  workshop  participants  to  have  a  common  understanding  why  the 
SEI  was  there  and  what  the  SEI  was  planning  to  do  during  the  two-day  workshop. 


8.1.2  Results 

Col  Jevsevar  presented  a  slide  presentation  to  outline  the  purpose  and  the  objectives  of  the 
workshop.  In  addition,  he  called  for  full  participation  from  everyone  and  open 
communications 


8.1.3  Discussion 

See  Appendix  A  for  Col  Jevsevar’s  slide  presentation. 


8.2  Agenda  item  “Introductions” 

The  next  topic  was  an  introductions  section. 


8.2.1  Desired  Outcomes 

Each  workshop  participant  had  an  opportunity  to  introduce  themselves  and  state  their 
“wants/offers.” 
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8.2.2  Results 


The  facilitators  stated  the  roles  and  rules  of  the  workshop.  Participants  introduced  their  name 
and  their  role  in  SSG  or  in  the  SEI.  Then,  each  participant  was  given  two,  different  colored, 
large-sized  post-it  notes.  They  were  instructed  to  write  their  wants  on  one  post-it  and  their 
offers  on  the  other  post-it.  When  they  were  done  writing,  they  came  to  the  front  of  the  room 
and  placed  their  wants  on  one  of  the  easel  pads  and  their  offers  on  the  other  easel  pad.  The 
facilitators  then  read  through  all  of  the  offers  and  lined  them  up  against  the  workshop 
objectives.  In  general,  the  wants  and  offers  provided  were  appropriate  for  the  intended  scope 
of  the  workshops. 


8.2.3  Discussion 

See  Appendix  B  for  raw  data  collected  from  this  section. 


8.3  Agenda  item  “Review/Agree  on  workshop 
objectives”  Summary 

Next  on  the  agenda,  participants  reviewed/agreed  upon  the  workshop’s  objectives. 


8.3.1  Desired  Outcomes 

The  desired  outcome  of  this  agenda  topic  was  for  all  participants  to  come  to  agreement  on  the 
agenda  and  understanding  of  objectives. 


8.3.2  Results 

Participants  reviewed  the  workshop  objectives  and  refined  the  agenda.  Key  points  were 
captured  on  a  flip  chart. 


8.3.3  Discussion 

The  data  collected  from  this  agenda  item  is  in  Appendix  J. 
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8.4  Gunter  to  provide  review  of  SSG’s  strategic 
objectives 

Next,  SSG  provided  a  review  of  their  strategic  objectives. 


8.4.1  Desired  Outcomes 

All  participants  were  to  have  a  common  understanding  of  SSG’s  objectives/plans. 


8.4.2  Results  Summary 

Rick  Plaskett,  from  SSG  provided  a  slide  presentation  that  reviewed  all  of  SSG’s  strategic 
objectives.  The  result  of  this  review  and  discussion  was  that  the  strategic  priorities  had  not 
changed  much  since  the  plan  was  produced.  This  provided  a  stable  basis  for  moving  forward. 


8.4.3  Discussion 

See  Appendix  C  for  Rick  Plaskett’s  slide  presentation. 


8.5  Review  SEI  work  plan/connect  to  SSG  objectives 

The  next  topic  on  the  agenda  was  a  review  of  the  SEI  work  plan  and  how  it  connected  to 
SSG’s  strategic  objectives. 


8.5.1  Desired  Outcomes 

The  desired  outcome  from  this  section  was  a  common  understanding  of  how  SEI’s  ideas  map 
to  SSG’s  objectives. 


8.5.2  Results  Summary 

Jan  Vargas,  SEI  Tech  Lead,  gave  a  brief  overview  of  the  SEI  work  plan.  Then,  each  SEI 
technology  lead  talked  for  15  minutes  on  their  particular  technologies,  as  outlined  below. 

•  Gian  Wemyss:  People  Capability  Maturity  Model  (P-CMM) 

•  Grady  Campbell:  Enterprise  Architecture 

•  Dan  Plakosh:  Software  Sustainment  and  Modernizing  Legacy  Systems 
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•  Kristi  Keeler:  Capability  Maturity  Model  -  Integrated  (CMMI) 

•  John  Foreman:  COTS-Based  Systems 

8.5.3  Discussion 

SEI  Work  Plan  Version  1.40  is  in  Appendix  D,  and  each  SEI  technology  lead’s  slide 
presentation  is  located  in  Appendix  E  through  1. 


8.6  Create  map  of  SSG’s  object ives/S El  connections 

Create  map  of  SSG’s  objectives/SEI  connections. 


8.6.1  Desired  Outcomes 

Create  a  map  of  SEI  technologies  showing  explicit  connections  to  various  SSG  strategic 
objectives  and  the  balanced  scorecard.  There  were  21  SSG  objectives.  These  objectives 
were  grouped  into  three  categories:  customer  focused,  internal  operations,  and  innovation  and 
learning. 


8.6.2  Results  Summary 

A  mapping  exercise  of  SSG  needs  to  SEI  expertise  was  conducted.  First,  the  SSG  issues 
related  to  three  strategic  goal  clusters  were  gathered.  The  goal  clusters  were  as  follows: 

•  Customer-focused 

•  Internal  operations 

•  Innovation  and  learning 

Then  SEI  subject  matter  experts  mapped  SEI  technologies  that  could  help  solve  the  issue 
where  feasible.  The  first  three  maps  in  Appendix  K  reflect  this  perspective.  Then  the  maps 
were  reversed,  with  SEI  technologies  at  the  center  and  the  associated  SSG  issues  highlighted. 
These  maps  were  used  together  to  support  the  prioritization  activities  of  day  two. 

8.6.3  Discussion 

The  Mind  Map  that  was  generated  for  this  exercise  can  be  found  in  Appendix  K. 
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9  Agenda  Items,  Day  2,  October  28,  2003 


9.1  Review  Day  1  work;  revise  as  necessary 

The  first  topic  on  day  two’s  agenda  was  a  review  of  day  one  work. 


9.1.1  Desired  Outcomes 

Participants  were  to  reset  on  where  we  left  off  the  previous  day. 

9.1.2  Results  Summary 

Workshop  facilitators  “walked  the  wall,”  reviewing  day  one  results,  and  proposed  day  two’s 
agenda.  See  Table  5  for  the  agenda  used  for  day  two. 


9.2  Prioritize  SEI  work  plan  tasks 

The  next  agenda  topic  on  day  two  was  to  prioritize  SEI  work  plan  tasks. 


9.2.1  Desired  Outcomes 

The  workshop  participants  put  SEI’s  tasks  in  prioritized  order. 


9.2.2  Results  Summary 

A  mapping  exercise  of  SSG  needs  to  SEI  expertise  was  carried  out.  SSG  attendees  “dot 
voted”  on  the  major  three  areas  they  thought  were  most  important  for  SSG  to  follow  in  the 
near  term.  The  top  three  tasks  that  were  chosen  were  COTS  systems  support/integration,  P- 
CMM,  and  Process  Improvement. 
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9.3  Perform  readiness/fit  analysis  for  top  3  tasks 

The  next  item  was  to  perform  a  readiness/fit  analysis  for  the  top  three  tasks. 


9.3.1  Desired  Outcomes 

The  desired  outcome  for  this  item  was  to  develop  a  risk  list  related  to  the  top  three  SEI  tasks 
and  create  a  risk  profile  for  each. 


9.3.2  Results  Summary 

This  task  was  replaced  by  a  task  to  elicit  barriers  and  enablers  for  each  of  the  top 
technologies.  Readiness/fit  analysis  was  deemed  too  detailed  an  approach  for  this  workshop. 


9.3.3  Discussion 

The  raw  data  collected  from  the  easel  paper  is  part  of  the  Appendix. 

-  COTS  systems  support/integration,  Appendix  L 

-  P-CMM,  Appendix  M 

-  Process  Improvement.  Appendix  N 


9.4  Engagement  for  pilots  task  planning 

Engagements  for  pilot  task  planning. 


9.4.1  Desired  Outcomes 

Interested  SSG  2-letter  organizations  were  identified  as  partners  for  each  task  and  then 
individuals  from  these  organizations  volunteered  to  be  the  primary  points  of  contact. 
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9.4.2  Results  Summary 

The  following  individuals  are  the  primary  points  of  contact: 


-  COTS  systems  support/integration  -  Steve  Wright  (EN) 

-  P-CMM  -  Lt  Col  Ingenloff  (DP) 

-  Process  Improvement  -  Tom  Speakman  (XPJ) 


9.5  Close  up  main  part  of  workshop 

9.5.1  Desired  Outcomes 

Participants  evaluated  the  meeting. 


9.5.2  Results  Summary 

Facilitators  asked  the  workshop  participants  if  there  was  anything  they  liked  about  the 
workshop  and  is  there  anything  that  the  SEI  could  improve  upon.  SSG  attendees  not  directly 
involved  in  the  pilot  tasks  could  leave  the  workshop  at  this  time. 

In  general,  the  reaction  to  the  workshop  was  positive.  Individual  items  for  improvement  were 
noted  and  will  be  incorporated  into  future  technology  adoption  events  as  appropriate. 

This  table  outlines  what  the  workshop  attendees  liked  about  the  workshop  and  what  they 
would  change  about  the  workshop. 


Table  6:  Workshop  Report  Summary  -  Pluses  and  Deltas 


Pluses 

Deltas  (Changes) 

Validated  issues  we  see  in  practice  outside  in  our  work 

Explain  purpose/better  preparation  ahead  of  time 

In-process  artifacts 

Strategic  vision  was  50K,  not  500  ft  view 

Got  us  thinking  about  things  we  need  to  do 

How  not  to  lose  other  important  areas 

Clarify  summation/traceability  from  possible  final 

choices 
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9.6  Task  planning 

The  final  agenda  topic  was  task  planning. 


9.6.1  Desired  Outcomes 

The  SSG  primary  points  of  contact  and  the  SEI  technology  leads  met  and  discussed  how  they 
were  going  to  carry  out  the  top  three  tasks. 

•  COTS  systems  support/integration 

•  P-CMM 

•  Process  Improvement 

9.6.2  Results 

Each  of  the  three  groups  met  for  approximately  two  and  a  half  hours  to  discuss  the  goals, 
picture  of  success,  success  criteria,  tasks  for  the  next  three  months,  and  ties  to  the  balanced 
scorecard  clusters:  innovation/learning,  internal  operations,  and  customer  focus. 

Section  10  contains  the  next  steps  agreed  on  for  each  task. 
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10  Workshop  Report  Summary 


10.1  Summary  of  Next  Steps  for  SEI  Tasks 

10.1.1  COTS 

The  SEI  is  an  acknowledged  expert  in  the  techniques  and  practices  necessary  to  develop  and 
evolved  software  systems  which  are  based  on/extensively  utilize  COTS  products,  as  opposed 
to  building  systems  completely  from  scratch.  Using  COTS  products  requires  new  or  alternate 
processes  and  practices  throughout  the  system  life  cycle,  to  include  but  not  limited  to 
business  case  evaluation,  requirements  definition,  vendor  and  supplier 
relationships/management,  architecture,  product  evaluation,  risk  management,  and  more. 
Using  COTS  products  also  requires  ongoing  tradeoffs  be  made  among  the  system  context 
(requirements,  cost,  schedule,  business  processes),  the  system’s  architecture/design,  and  the 
product  marketplace. 


10.1.2  People  Capability  Maturity  Model  (P-CMM) 

The  P-CMM  framework  helps  organizations  successfully  address  their  critical  people 
issues.  Based  on  the  best  current  practices  in  fields  such  as  human  resources,  knowledge 
management,  and  organizational  development,  the  People  CMM  guides  organizations  in 
improving  their  processes  for  managing  and  developing  their  workforces.  As  such,  the 
SEI  will  work  with  SSG  to  deliver  the  following:  P-CMM  workshop,  P-CMM  Gap 
Analysis  Findings  and  Recommendations  Report,  Action  Planning  workshop  and 
resulting  improvement  plan.  Improvement  Teams  workshop,  P-CMM  coaching  and 
assistance. 


10.1.3  Process  Improvement 

The  SSG  Software  Engineering  Process  (SEP)  document  contains  a  well  written  set  of 
processes  that  can  facilitate  the  transition  from  the  S W-CMM  to  the  CMMI-SE/S W  V 1 . 1 . 
The  outcome  from  the  Technology  Adoption  Planning  Workshop  indicates  that  CMMI 
adoption  is  an  appropriate  step  for  SSG. 
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The  SEI  will  provide  assistance  in  developing  detailed  SEP  to  CMM1-SE/S  W  V 1 . 1  gap 
analysis,  understanding  and  interpreting  the  CMMI  reference  model  and  in  developing 
processes  that  are  consistent  with  the  practices  contained  therein. 
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Appendix  A  Presentation:  Col  Jevsevar’s 

HQ  Standards  Systems 
Group 


This  appendix  contains  the  presentation  “Col  Jevsevar’s  HQ  Standards  Systems  Group.” 
These  slides,  presented  on  Monday,  October  27,  2003,  outlined  why  we  were  attending  the 
workshop,  the  purpose  of  the  workshop,  and  expected  outcomes. 


Proud  Heritage 
Bright  Future 


HQ  Standard 
Systems  Group 
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Appendix  B  Wants  and  Offers 


This  appendix  contains  the  list  of  the  workshop  “wants”  and  “offers”  from  the  second  item  on 
the  Monday,  October  27  agenda  presented  in  Table  4. 

Offers 

•  Technology  adoption  tools/techniques.  Facilitation  for  workshop,  (sg) 

•  Honesty,  integrity,  “can  do”  attitude.  Vision  for  SSG  workforce  &  business  goals. 
(Ingeloff) 

•  Gap  analysis/fit  determination  with  regard  to  CMMI  &  other  models,  (klk) 

•  Contracting  expertise,  (wdm) 

•  Acquisition  background,  (tb) 

•  Strategic  planning  process  skills.  Understanding  of  metrics  development,  (rp) 

•  Background/skills  in  strategic  planning  &  program  evaluation.  (In) 

•  26  years  in  IT  solutions.  I  have  a  good  understanding  of  user  needs,  (dw) 

•  Insight  into  how  organizations  can  unify  business  &  technology  views  of  their 
organizational  mission,  (ghc) 

•  Facilitate  communication.  (jmv) 

•  An  integrated  view  of  SEI  technologies  &  a  promise  to  adapt  &  tailor  as  needed,  (jtf) 

•  Offer  financial  expertise  and  outcomes  obtained  and  processes  reviewed  during 
transformation  initiatives,  (tcp) 

•  Knowledge  of  DoD  modernization  plans. 

•  1  will  guarantee  that  the  SSG  needs  are  met  through  close  internal  SEI  collaboration,  (lm) 

•  Insight  to  customer  concerns  &  perceptions  about  SSG.  Insight  to  the  role/concerns  of 
SSG’s  enlisted  personnel. 

•  Robust  legal  advice  to  enhance  mission  and  achieve  SSG  vision,  (jeh) 

•  CM  experience,  (jhh) 

•  Personal  experience  with  process  implementation. 

•  Experience  with  P-CMM.  Lessons  learned  from  other  organizations  using  PCMM, 
CMMI.  Facilitation  skills,  (rgw) 
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•  Creative  thinking. 

•  Sense  of  humor.  Acquisition  &  engineering  experience,  (vgj) 

•  Central  point  for  all  SSG  business  processes,  (hs) 


Wants 

•  Workshop  results  that  support  a  productive  relationship  w/SSG.  (suz) 

•  True  strategic  vision  -  capture  essence  of  what  each  2-ltr  shall  play. .  .all  in  synch 
w/SSG’s  future,  corporate  goals,  (pi) 

•  Meaningful,  short  strat  plan  which  can  be  communicated  easily  to  every  person  in  SSG. 
Limited  metrics,  (tb) 

•  Understanding  of  what  s  new  technology  is  so  that  a  roadmap  for  execution  can  be  built, 
(wdm) 

•  A  prioritized  list  of  SSG’s  strategic  objectives  tied  to  specific  tasks  in  the  SEI  workplan 
(by  end  of  workshop).  (In) 

•  SSG  2-ltr  buy-in  of  technology  priorities.  SSG  strategic  plan,  (vgj  ) 

•  Result  -  clear  understanding  of  what  the  next  steps  are.  (jmv) 

•  Insight  into  how  SSG  can  transform  itself  into  a  software  center  of  excellence,  (jha) 

•  Everything  we  say  we  are  going  to  do  has  a  measurable  method  of  determining  success 
(or  not),  (rp) 

•  Co-workers  thoughts  on  how  to  maximize  support  to  our  customers  worldwide,  (ldw) 

•  Understand  SSG  business  objectives  &  alignment/appropriateness  fit  of  models  & 
technology,  (klk) 

•  A  productive  workshop  that  helps  clarify  our  strategic  objectives,  (jhl) 

•  Enhance  SSG’s  ability  to  become  the  IT  center  of  excellence  for  the  war  fighter,  (jeh) 

•  Understand  SSG  status,  goals  &  needs  for  improvement,  (ghc) 

•  Feedback  from  other  SSG  2-ltrs  on  objectives/CMM,  etc. 

•  Want  to  achieve  an  understanding  of  measurements  we  can  use  to  gauge  the  success  of 
transformation,  (tcp) 

•  Results  that  helps  transformation  bring  new  business  process  into  SEPG.  (hs) 

•  Understand  SSG’s  strategic  objectives  and  the  people  issues  (knowledge,  skills,  abilities) 
associated  with  these  objectives,  (rgw) 

•  To  see  a  clear  strategic  plan  that  parallels  the  transformation  activities  within  the 
organization,  as  well  as  meeting  the  AF’s  IT  needs. 
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•  Agreement  on  at  least  one,  but  ideally  three  strategic  objectives  that  we  will  jointly 
achieve  together  in  1-2  years. 

•  To  ensure  I  have  a  clear  understanding  of  the  planned  work  activities  for  the  SSG 
customer,  (lm) 

•  Better  understanding  of  how  to  mix  technology  advances  into  legacy  sustainment. 

•  Some  ideas  about  what  not  to  measure  as  we  adopt  balanced  scorecards,  (jc) 

•  Ideas  for  ways  to  assess  that  SSG  is  “in  the  loop”  on  new  technologies,  (jc) 

•  Clearer  vision  of  how  to  transition  ST  to  better  support  the  SSG  strategic  goals,  (jc) 

•  Successful  workshop  in  that  a  “roadmap”  for  upcoming  work  is  defined  &  we  can 
proceed  to  more  details  &  implementation,  (jtf) 
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Appendix  C:  Issues  and  Comments 


These  issues  and  comments  were  generated  during  the  workshop  on  Monday,  October  27, 
2003. 

Spiral  acquisition  strategies 

•  Adding  increments  adds  other  overhead  (e.g.  AFCA)  that  is  outside  control  of  SSG 

Develop  technical  expertise 

•  Place  to  add  “portal  skills”  explicitly 

CMMI  Level  3 

•  How  do  people  get  refreshed 
GCSS  -AF  compliance 

•  Update  to  include  current  ESC  architecture  requirements 
SEP 

•  Perception  of  SEP  as  “obstacle”  wider  spread  than  it  should  be  based  on  results  achieved 
with  SEP 

ID  right  mix  of  skills 

•  Remove  overhires 

•  Merge  this  slide  w/other  2  BSC  slides  related  to  skills 
Missing? 

•  Charge  back  of  DP/other  staff  ??  to  2-letters 

o  How/when? 
o  Where  does  it  fit? 
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Appendix  D:  SSG’s  Strategic  Objectives 


The  following  PowerPoint  slides,  presented  by  Rick  Plaskett  on  October  27,2003,  outline  the 
objectives  for  SSG. 
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Appendix  E:  SEI  Work  Plan 


This  work  plan  was  distributed  at  the  workshop  on  October  27,2003. 


Fiscal  Year  2003-04  Work  Plan 

FOR  THE 

Standard  Systems  Group  (SSG) 

PWS  4-198 
Version  1 .40 


Howard  Stubblefield  Date 

Standard  Systems  Group/XP 


Thomas  C.  Brandt  Date 

Program  Integration  Directorate 
Software  Engineering  Institute 


John  Foreman  Date 

Air  Force  Chief  Engineer 
Acquisition  Support  Program 
Software  Engineering  Institute 
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Work  Plan  Change  Log 


This  section  contains  a  history  of  changes  made  to  the  Work  Plan. 


Ver  # 

Description  of  Change 

Date 

1.0 

Initial  draft  FY03  work  plan 

4/15/03 

1.1 

Incorporated  changes  from  jtf,  cpg,  res,  and  Ken  Heitkamp 

5/6/03 

1.2 

Changed  signatory  to  Howard  Stubblefield,  revised  task  2.2  (Technology  Adoption  Planning 

Workshop),  revised  task  2.8  (COTS-Based  Systems),  added  task  2.9  (Enterprise  Architecture), 

revised  the  cost  estimates  to  reflect  FY04  overhead  rates 

6/17/03 

1.35 

•  Formatting  changes  in  the  task  table. 

•  Edits  to  most  of  the  task  descriptions. 

•  Rewrote  2.5 

30  July  03 

1.38 

•  Changed  Tech  lead,  changed  account  exec. 

•  Changed  Account  exec  title  to  “Business  Manager”. 

•  Added  background  section  (section  2)  to  explain  the  project  history  -  all  section  #s  2  and 
higher  are  now  3  and  higher 

1.40 

•  Miscellaneous  layout  and  formatting  changes 

•  Added  Executive  CMMI  intro  course  to  the  CMMI  section 

•  Incorporated  results  of  the  Sept  03  TIM  w/Gunter  people 

Oct  03 

The  information  listed  below  must  be  completed: 


Name  of  Organization:  Standard  Systems  Group 

Point  of  Contact:  Howard  Stubblefield 

Street  Address:  490  E.  Moore  Drive 

Bldg  892 

City,  State,  Zip  Code:  Maxwell  AFB-Gunter  Annex, 

AL  36114 

Phone  #:  334-416-4041 

Fax  #:  334-416-5505 

E-mail  address:  Bloise.Stubblefield@Gunter.AF.mil 
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PWS  4-198 

Standard  Systems  Group 
Work  Plan 
Version  1.40 
CDRLA002 


Customer: 

SEI  Business  Manager: 
SEI  Technical  Lead: 

SEI  Chief  Engineer: 
Period  of  Performance: 


Standard  Systems  Group 

Maxwell  AFB-Gunter  Annex,  AL  36114 

Lisa  Masciantonio 

Jan  Vargas 

John  Foreman 

20  Sep  03  through  30  Sep  04 


Introduction 


This  Work  Plan  outlines  the  work  that  members  of  the  Software  Engineering  Institute  (SEI) 
will  perform  under  PWS  4-198  for  the  Standard  Systems  Group  (SSG)  during  the  period  20 
Sep  03  through  30  Sep  04. 

The  intent  of  the  SEI  support  detailed  in  this  Work  Plan  is  to: 

•  help  SSG  understand  and  use  pertinent  software  engineering  technologies  and 
processes; 

•  assist  SSG  to  improve  its  software  acquisition  practices;  and 

•  assist  SSG  in  various  transformation  efforts. 

This  Work  Plan  may  be  revised  to  reflect  new  agreements  between  the  SSG  and  the  SEI. 
Changes  to  this  Work  Plan  will  require  the  approval  of  the  authorized  persons  from  the  SSG 
and  the  SEI  and  will  be  documented  in  the  Work  Plan  Change  Log  on  page  2. 

Additional  background  information  can  be  found  in  PWS  4-198. 

Background 

In  late  CY02,  the  SEI  was  asked  by  the  new  SSG  director,  Mr.  Frank  Weber,  to  perform  an 
“enterprise  assessment”  of  SSG.  SSG’s  goal  is  to  establish  itself  as  a  Center  of  Excellence 
(CoE)  for  Air  Force  combat  support  Information  technology  (IT)  systems.  Given  that  goal, 
SSG  asked  the  SEI  to  provide  initial,  objective  insights  on  core  SSG  processes/organizations 
that  are  critical  to  establishing  this  CoE,  to  include: 

•  roles/relationships  between  the  Program  Offices  and  Software  Factory; 

•  Skills  mix  required  to  support  future  AF  IT  environment,  to  include  best  balance  of 
blue  suit  vs.  government  civilian  vs.  contractors  considering  legacy  system 
requirements,  modernization/technology  evolution  and  training 
requirements/capabilities; 

•  Core  competencies  to  promote  an  integrated  combat  support  system  domain;  and 

•  Basic  organizational  strategies. 

Initial  work  culminated  in  a  17  Jan  03  briefing,  which  addressed  areas  of  Apparent  Strength 
and  Areas  of  Apparent  Concern  toward  the  accomplishment  of  this  goal. 
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Further  investigation  to  include  interviews  and  discussions  with  various  Air  Force  leaders 
resulted  in  a  more  detailed  presentation  and  a  closeout  of  the  “discovery  phase”  on  8  May 
03. 

The  tasking  in  this  work  plan  is  the  direct  result  of  the  aforementioned  assessment  out  briefs 
and  ongoing  discussion/direction  from  SSG  leadership  and  is  meant  to  be  consistent  with  Mr. 
Weber’s  stated  goals: 

•  Make  SSG  Easy  to  do  business  with  ...  as  deemed  by  our  customers! 

•  Streamlined  organization  with  agile  processes; 

•  Recognized  expertise  in  exploring  and  exploiting  leading  IT  technologies; 

•  Enterprise-wide  perspective. 

Tasking 

Project  Management 

The  SEI  shall  coordinate  the  planning,  implementation,  and  delivery  of  the  support  defined  in 
this  Work  Plan.  The  SEI  will: 

•  provide  on-going  customer  interface,  coordination,  planning  and  support  to  ensure 
services  and  products  are  satisfactorily  delivered; 

•  provide  experienced  SEI  members  of  the  technical  staff  to  support  the  SSG; 

•  present  status  and  progress  briefings/reports  to  both  the  SEI  and  the  SSG;  and 

•  track  deliverables  and  progress  against  plans,  and  track  the  expenditure  of  funds 
against  schedules,  milestones,  and  deliverables. 

Refer  to  section  4  of  the  PWS  for  project  management  reporting  deliverables. 

Sections  3.2  through  3.10  define  suggested  tasking  for  this  work  plan.  These  tasks  address 
technology  adoption  planning,  workforce  management,  techniques  for  improving  sustainment 
of  existing  systems,  modernizing  legacy  systems,  portfolio  management,  CMMI  adoption 
planning,  COTS-based  systems,  and  enterprise  architecture. 

Technology  Adoption  Planning  Workshop 

The  workshop  is  specifically  focused  on  producing  a  working  plan  for  incorporating 
technologies  in  the  SEI  work  plan  into  the  SSG  transformation  activities.  The  workshop  will 
begin  by  reviewing  the  objectives  and  achievement  strategies  in  the  SSG  FY03-08  Strategic 
Plan  (Aug  22,  2002)  to  validate  that  they  are  still  relevant  in  the  context  of  recent 
organizational  changes  and  priority  changes.  Working  with  the  SSG  leadership  team,  the  SEI 
will  collaborate  in  planning  and  prioritizing  the  adoption  of  the  technologies  proposed  in  this 
FY03-04  work  plan.  These  will  be  explicitly  connected  to  the  SSG  strategic  objectives  in 
order  to  provide  maximum  benefit  to  SSG  in  achieving  said  objectives. 

The  SEI  will  work  with  SSG  prior  to  the  workshop  to  establish  the  agenda  and  identify 
appropriate  participants.  Attendees  at  the  workshop  should  include  the  Executive  Director  of 
SSG,  his  direct  reports,  and  staff  members  who  will  be  responsible  for  implementing, 
monitoring,  and  controlling  the  transformation  effort. 

Deliverable:  An  output  of  the  workshop  will  be  a  prioritized  list  of  SSG’s  strategic  objectives 
tied  to  specific  tasks  in  this  SEI  work  plan.  In  addition  to  creating  the  prioritized  list  of  tasks, 
sequencing  (i.e.,  education/training,  consulting,  etc.)  of  the  subtasks  will  be  discussed  and 
documented. 

People  Capability  Maturity  Model  (P-CMM)  Gap  Analysis  and 
Improvement  Plan 
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One  of  the  findings  from  the  Enterprise  Assessment  was  that  in  order  for  SSG  to  meet  its 
transformation  goals,  SSG  will  need  to  fill  certain  skills,  abilities,  and  knowledge  gaps  in  their 
workforce.  Assuming  that  the  Technology  Adoption  Planning  Workshop  (section  3.2) 
confirms  the  aforementioned  need  as  a  priority,  SEI  recommends  launching  this  effort  with  a 
P-CMM  gap  analysis  of  SSG’s  people  management  capability.  The  P-CMM  gap  analysis  will 
involve  structured  interviews  by  SEI  with  SSG  process  owners  (from  DP,  work  environment 
(facilities)  management,  security,  safety,  and  IT),  managers,  and  representatives  of  the 
workforce.  At  a  workshop,  the  findings  from  these  interviews  will  be  analyzed  and 
synthesized  into  recommendations  for  improvement  in  the  form  of  an  improvement  plan.  The 
output  of  the  workshop  will  show  how  SSG’s  processes  for  workforce  management  are 
structured  to  meet  the  mission  (these  are  opportunities  for  leverage)  and  where  the  gaps  are 
that  could  be  inhibiting  factors  in  the  transformation. 

Workshop  attendees  should  include  leadership  from  DP,  technical  staff,  and  middle 
management.  SEI  will  work  with  SSG  to  identify  these  individuals.  Also,  SEI  will  require  the 
participation  of  2-3  SSG  personnel  and  a  member  of  the  DP  organization  for  approximately 
one  week,  full  time,  to  contribute  to  the  gap  analysis  activities  and  the  development  of  the 
recommendations  and  improvement  plan.  SEI  will  work  with  SSG  to  identify  appropriate 
personnel. 

Deliverable:  P-CMM  Gap  Analysis  findings,  Workshop,  Improvement  plan 

Software  Sustainment  -  Measured  Improvement  of 
Sustainment  Processes 

Most  systems  that  are  SSG’s  responsibility  are  in  the  sustainment  phase.  This  task  will 
define  and  apply  sustainability  measures  to  sustainment  projects  at  SSG,  identify  and 
measure  causal  factors  that  can  be  correlated  to  sustainability  measures,  and 
implement/transition  a  process  of  metrics-based  continuous  sustainment  process 
improvement  to  SSG. 

The  SEI  is  currently  developing  processes  and  technical  practices  that  focus  on  improving 
the  performance  of  sustainment  activities.  In  order  to  pilot  and  transition  these  techniques,  an 
SEI  team  will  perform  two  sustainability  assessments  with  SSG  observers.  The  output  from 
these  assessments  will  be  a  sustainability  profile  consisting  of  an  annotated  set  of  Excel 
reports.  The  SEI  will  then  develop  training  materials  and  train  up  to  10  sustainment 
assessors  on-site  at  SSG.  The  SEI  will  accompany  an  SSG  assessment  team  during  the  first 
SSG-lead  sustainability  assessment. 

Deliverable:  Sustainability  profile  reports,  On-site  training,  Coaching/evaluation  during  SSG 
assessment 

Modernizing  Legacy  Systems 

A  growing  need  in  the  emerging  Air  Force  IT  environment  will  be  to  evolve  and  modernize 
legacy  systems  to  incorporate  new  technologies,  function  in  Web-based  environments, 
achieve  horizontal  integration  and  interoperability,  and  consolidate  into  Common  applications 
and  processes  across  AF/DoD.  The  SEI  has  developed  processes  and  technical  practices 
that  focus  on  system  modernization  and  evolution  as  well  as  building  new  systems  using 
advanced  technologies  such  as  commercial  components. 


This  task  will  enhance  and  grow  SSG’s  skill  sets  in  modernization,  web-based  technologies, 
interoperability,  design  and  architectural  alternatives,  etc.  The  SEI  will  provide  training  in 
both  Modernizing  Legacy  Systems  and  Building  Systems  from  Commercial  Components  on¬ 
site  at  SSG.  The  SEI  will  provide  direct  support  and  consultation  for  design  and  architecture 
reviews  for  two  selected  programs,  which  focus  on  major  modernization  efforts  and  new 
Java-based  developments.  To  transition  these  techniques  to  SSG  personnel,  and  stimulate  a 
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culture  of  continuous  growth  and  improvement,  the  SEI  will  assist/coach  an  SSG  team  as  it 
performs  a  design/architecture  review  for  a  legacy  system  modernization. 

Deliverable:  On-site  training,  direct  support  and  consultation  for  design  and  architecture 
reviews,  coaching  during  SSG  review 

Portfolio  Management  and  Integration 

Portfolio  management  refers  to  a  process/activity  that  establishes  measures  of  technical 
quality  and  business  value  for  the  set  of  systems  under  SSG  control  and  then  evaluates  the 
set  against  the  measures.  Business  value  measures  the  number  and  criticality  of  the 
business  goals  supported  and  the  degree  to  which  these  goals  represent  core  competencies 
of  the  business.  Technical  quality  measures  vary  based  upon  business  requirements  but 
may  include  sustainability,  evolvability,  usability,  performance,  availability,  security  and  other 
system  qualities. 

This  task  will  establish  criteria  for  measures  of  technical  quality  and  business  value.  Then, 
beginning  with  a  list  of  key  SSG  systems,  this  task  will  determine  appropriate 
evolution/migration  strategies  for  each  (to  include  evolution  towards  the  GCSS  AF  Integration 
Framework  (GCSS-AF  IF)  and  work  with  SSG  management  to  prioritize  and  assign 
appropriate  resources  to  these  efforts. 


Deliverable:  Systems  evolution  assessment,  High-level  plan  for  system  evolution 

Changes  still  to  be  made  to  3.6  to  more  clearly  indicate  how  the  measures  of  technical  quality 
and  business  value  get  established.  And  how  are  they  used  to  determine  appropriate 
evolution/migration  strategies. 

CMMI  Adoption  and  Implementation  Planning 

In  3Q02,  an  SSG-requested  assessment  of  SSG’s  Systems  Engineering  Process  (SEP)  was 
conducted.  The  assessment  compared  the  existing  SEP  to  the  CMMI-SE/SW  VI  .1 .  The 
majority  of  the  gaps  in  coverage  that  were  found  resulted  from  the  SEP  being  Software  and 
SW-CMM  oriented.  The  SEP  contains  a  well  written  set  of  processes  that  can  facilitate  the 
transition  from  the  SW-CMM  to  the  CMMI  SE/SW  VI  .1 . 

If  the  outcome  from  Task  3.2  (Technology  Adoption  Planning  Workshop)  indicates  that  CMMI 
adoption  is  an  appropriate  step  for  SSG,  then  the  SEI  can  provide  assistance  in 
understanding  and  interpreting  the  CMMI  reference  model  and  in  developing  processes  that 
are  consistent  with  the  practices  contained  therein.  In  order  to  move  forward  in  this  area,  the 
SEI  will  present  the  Executive  CMMI  intro  course  and  utilize  findings  from  an  Adoption 
Readiness  and  Fit  Analysis  to  assess  SSG’s  readiness  for  adopting  and  implementing  each 
of  the  identified  CMMI  practices  and  the  potential  risks  associated  with  each  practice.  These 
findings  will  then  be  used  to  build  an  Improvement  Plan,  which  will  lay  out  specific  steps  to 
mitigate  high  risk  areas,  and  describe  steps  for  implementing  the  CMMI  practices  for  which 
SSG  is  ready. 

Deliverable:  Executive  CMMI  intro  course,  Readiness  and  Fit  Analysis,  Improvement  Plan 
for  implementing  CMMI  practices. 

COTS-Based  Systems 

The  SEI  is  an  acknowledged  expert  in  the  techniques  and  practices  necessary  to  develop 
and  evolve  software  systems  which  are  based  on/extensively  utilize  COTS  products,  as 
opposed  to  building  systems  completely  from  scratch.  Using  COTS  products  requires  new  or 
alternate  processes  and  practices  throughout  the  system  life  cycle,  to  include  but  not  limited 
to  business  case  evaluation,  requirements  definition,  vendor  and  supplier 
relationships/management,  architecture,  product  evaluation,  risk  management,  and  more. 
Using  COTS  products  also  requires  ongoing  tradeoffs  be  made  among  the  system  context 
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(requirements,  cost,  schedule,  business  processes),  the  system’s  architecture/design,  and 
the  product  marketplace. 


The  SEI  will  provide  SSG  with  training  and  workshops  addressing  the  various  key  aspects  of 
using  COTS  products,  and  transition  new  risk  management,  and  life  cycle  management 
processes.  The  SEI  will  also  provide  consulting  in  technology  insertion  and  adoption, 
especially  in  the  context  of  proper  approaches/processes  for  using  Enterprise  Resource 
Planning  (ERP)  systems. 

Deliverable:  Training  and  workshops,  Consulting,  White  paper  on  ERP. 

Enterprise  Architecture 

The  SEI  will  work  with  SSG  to  develop  an  enterprise  architecture  that  covers  business 
architecture,  data  architecture,  application  architecture,  and  IT  architecture  to  produce  a  set 
of  guidelines  on  how  to  define  system  architectures.  This  enterprise  architecture  will  support 
C4ISP  support  plan  requirements,  be  implemented  using  C4ISR  architectural  views 
implemented  in  the  Unified  Modeling  Language  (UML),  and  incorporate  the  technical 
constraints  of  the  GCSS  AF  Integration  Framework  (GCSS-AF  IF).  The  enterprise 
architecture  will  initially  be  focused  on  a  set  or  subset  of  Air  Force  information  systems  to  be 
identified  by  SSG  management. 

Deliverable:  TBD 

Standard  SEI  Products  and  Services 

This  task  provides  SSG  with  the  normal  delivery  of  standard  SEI  products  and  services  (i.e., 
courses,  workshops,  tutorials,  publications,  and  events).  This  tasking  will  be  used/negotiated 
if  such  a  need  arises  during  the  period  of  this  work  plan.  Reporting  of  any  activity  under  this 
task  will  be  documented  in  the  Annual  Summary  Report. 

Technical  Assistance  and  Guidance 

This  task  provides  SSG  with  technical  assistance  and  guidance  related  to  the  SEI  initiatives 
and  expertise.  This  work  plan  includes  the  flexibility  to  accommodate  any  unforeseen 
support  requirements  requested  by  the  customer  within  the  defined  scope  and  in  accordance 
with  the  SEI  mission  and  initiatives.  Tasking,  deliverables,  cost,  and  schedule  for  all  involved 
parties  will  be  mutually  agreed  upon  and  documented  in  advance  of  task  execution. 

Reporting  of  supported  services  will  be  included  in  the  Annual  Summary  Report. 

Knowledge  Integration  and  Transfer 

The  SEI  will  capture  knowledge  from  this  engagement,  integrate  it  with  lessons  learned  from 
other  similar  work,  and  help  transfer  that  knowledge  for  the  betterment  of  the 
software/systems  engineering  and  acquisition  community.  This  may  include  but  is  not  limited 
to,  briefings,  technical  reports,  articles,  advocacy,  and  participation  in  building  an  acquisition 
community  of  practice. 

Deliverable:  Lessons  learned  report 
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Task  Summary 


Task  Summary 

SSG-PWS  4-198 


20  Sep  03  through  30 

Sep  04 

Task 

No. 

Task  Description 

Deliverable(s) 

Estimated 

Delivery  Date(s) 

Estimated 

Cost 

3.1 

Project  Management 

Management  and  Technical  Reports 

Various  per  PWS  #4-198 

$78,100 

3.2 

Technology  Adoption  Planning 

Workshop 

Technology  adoption  plan 

Anytime  after  the  work  plan  is 

signed  (&  depending  on 

availability  of  key  SSG 

personnel) 

$58,400 

3.3 

P-CMM  Gap  Analysis  and 

Improvement  Plan 

Gap  analysis  findings 

Workshop 

Improvement  plan 

TBD 

$48,700 

3.4 

Software  Sustainment 

Sustainability  profile  reports 

On-site  training 

Coaching/evaluation  during  SSG 

assessment 

TBD  ( 1  month  and  3  months 

after  task  start  date  ) 

TBD  (5  months  after  task  start 

date) 

TBD  (6  months  after  task  start 

date) 

$67,000 

3.5 

Modernizing  Legacy  Systems 

On-site  training 

Techniques,  guidance  in  and  direct 

support  for  architecture  and  design 

reviews 

Coaching/evaluation  during  SSG 

review 

TBD  (3  months  after  task  start 

date) 

As  needed 

TBD 

$75,000 

3.6 

Portfolio  Management  and 

Integration 

Systems  evolution  assessment 

High-level  plan  for  system  evolution 

As  needed 

As  needed 

$15,500 

3.7 

CMMI  Adoption  Planning 

Executive  CMMI  intro  course 

Readiness  and  Fit  findings 

Improvement  plan 

TBD 

$38,600 

3.8 

COTS-Based  Systems 

Training  and  workshops 

TBD 

$75,000 
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Task  Summary 

SSG-PWS  4-198 

20  Sep  03  through  30  Sep  04 

Task 

No. 

Task  Description 

Deliverable(s) 

Estimated 

Delivery  Date(s) 

Estimated 

Cost 

Consulting 

White  paper  on  ERP 

TBD 

TBD 

3.9 

Enterprise  Architecture  (EA) 

EA  description  to  include: 

•  briefings 

•  technical  report 

•  UML  Models 

TBD 

$100,000 

3.10 

Standard  SEI  Products  and 

Services 

TBD 

TBD 

TBD 

3.11 

Technical  Assistance  and 

Guidance 

TBD 

TBD 

TBD 

3.12 

Knowledge  Integration  and 

Transfer 

Lessons  learned  report 

TBD 

$25,000 

Total  Estimated  Cost 

Funding  provided  (end 

Sept  03) 

Remaining 

$581,300 

$350,000 

$183,400 

Note:  Estimated  costs  listed  above  include  staff  and  travel  costs.  Costs  are  estimates  only.  The  actual  cost  will 
depend  on  the  actual  staff  resources  that  are  used  and  travel  that  is  completed.  Only  actual  resources  expended, 
plus  actual  travel  costs  will  be  charged.  The  estimated  delivery  dates  listed  above  assume  the  availability  of  the 
needed  participants  from  SSG  and  a  Work  Plan  start  date  of  no  later  than  20  Sep  03.  Adjustments  may  be  required, 
based  on  actual  start  date  and  mutual  availability  of  SSG  and  SEI  staff. 
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Appendix  F:  People  Capability  Maturity 

Model  (P-CMM) 


Gian  Wemyss  gave  the  following  PowerPoint  presentation  at  the  workshop  on  October  27, 
2003. 


Carnegie  Mellon 

Software  Engineering  Institute 

Pittsburgh,  PA  15213-3890 

People  Capability  Maturity  Model® 
(People  CMM®)  version  2 

Gian  Wemyss 

Senior  Member  of  the 
Technical  Staff 

Capability  Maturity  Model  Team 

Sponsored  by  the  U.S.  Department  of  De 
©  2002  by  Carnegie  Mellon  University 
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Carnegie  Mellon 

Software  Engineering  Institute 


Improving  Organizations 


People 


Process 


©  2002  by  Carnegie  Mellon  University 


Technology 

page  2 


Carnegie  Mellon 

Software  Engineering  Institute 


What  Is  the  People  CMM  ? 

An  organizational  change  roadmap  based  on  state-of-the-art 
workforce  practices  to  help  organizations: 

9  Develop  the  workforce  required  to 
execute  organization  strategy 

•  Characterize  maturity  of  workforce 
practices 

•  Set  priorities  for  improving 
workforce  capability 

•  Integrate  improvements  in  process 
and  workforce 

•  originally  developed  with  support 
from  the  U.S.  Army  and  the  Office 
of  the  Secretary  of  Defense  Curtis,  Hetiey,  &  Miner  (2ooi> 

©  2002  by  Carnegie  Mellon  University  page  3 


Bill  Curtis 

William  E.  Hefley 

Sally  A.  Miller 
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Carnegie  Mellon 

Software  Engineering  Institute 


Founding  Advisory  Board 


Miriam  Browning 
Ed  Cotter 
Barry  Frew 
Paul  Garber 
Paul  Gehrmann 
Glenn  Gienko 
Marlene  Griffin-Bunnell 
Watts  Humphrey 
James  Jackson 
Cindy  Kendall 
Belkis  Loeng-Hong 
Sally  Mathews 
Jeff  McHenry 
Ron  Radice 
Roger  Sobkowiak 
Ed  Thompson 


U.S.  Army 

Digital  Equipment  Corporation 
Naval  Postgraduate  School 
Citicorp 

International  Business  Machines 

Motorola 

Eli  Lilly  &  Co. 

Software  Engineering  Institute 

Texas  Instruments 

Office  of  the  Secretary  of  Defense 

Defense  Information  Systems  Agency 

General  Services  Administration 

Microsoft 

Software  Technology  Transition 
Software  People  Concepts 
Advanced  Research  Projects  Agency 
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Carnegie  Mellon 

Software  Engineering  Institute 


People  CMM  Foundations 


Human  Res.  Mgt. 

•  process  domain 

•  best  practices 

•  goals  &  benefits 


Total  Quality  Mgt. 

•  process  &  performance 

•  quantitative  management 

•  continuous  improvement 

©  2002  by  Carnegie  Mellon  University 


Org.  Change  &  Devel. 

•  culture  &  maturity 

•  assess  &  improve 

•  change  management 
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Carnegie  Mellon 

Software  Engineering  Institute 


People  CMM-Based  Improvement 

•  Improvement  in  Workforc 
Capability 

•  The  model  helps  us 
understand  “what”  to  do. 

•  “How”  is  up  to  the 
organization. 

•  The  model  is  a 
roadmap. 

©  2002  by  Carnegie  Mellon  University 


Carnegie  Mellon 
Software  Engineering  Institute 

Why  Adopt  People  CMM? 

1 )  Become  ‘Employer  of  Choice’ 

2)  Enhance  organization  performance 

3)  Manage: 

•  intellectual  assets 

•  knowledge  capital 

4)  Measure  HR’s  contribution  to  the  business 

•  provides  common  measurement  framework 

•  allows  benchmarking  against  best  practices 


©  2002  by  Carnegie  Mellon  University 
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Carnegie  Mellon 

Software  Engineering  Institute 


Why  People  CMM  for  SSG? 

•  Enhance  Project  Management  Skills  Base. 

•  Develop  Your  Technical  Expertise. 

•  Communication  and  Coordination  of  the  SSG 
strategic  plan. 

•  Mitigate  the  loss  of  institutional  knowledge 
(employees  eligible  for  retirement,  opportunities 
from  other  organizations,  outplacement). 

•  Understand  what  investment  to  make  in  “smart” 
organic  workers. 

•  Establish  a  Culture  of  Human  Capital 
Management. 

©  2002  by  Carnegie  Mellon  University  page  8 


Peopl  e  C  M  M  E  A  rchi  tectu  re 


© 


Continuous  Workforce  Innovation 
Organizational  Performance  Alignment 
Continuous  Capability  Improvement 
Mentoring 

Organizational  Capability  Management 
Quantitative  Performance  Management 
Competency-Based  Assets 
Empowered  Workgroups 
Competency  Integration 
Participatory  Culture 
Workgroup  Development 
Competency-Based  Practices 
Career  Development 
Competency  Development 
Workforce  Planning 
Competency  Analysis 

Compensation 
Training  and  Development 
Performance  Management 
Work  Environment 
Communication/Coordination 
Staffing 
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Carnegie  Mellon 

-  Software  Engineering  Institute 

Staffing  Process  Example 
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Carnegie  Mellon 

Software  Engineering  Institute 

All  the  solutions  have  to  fit 


Staffing  r~ 

Performance 

xJ 

)  Management 

• 

f —  SSGfs — , 

Committed  Work 

— i  r 

v  Strategic  Objectives-x 

w 

Communication) 

(  Training 

and 

and 

Coordination 

Development 
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CamegieMellon 

Software  Engineering  Institute 


Questions  v 
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Appendix  G:  Enterprise  Architecture 


Grady  Campbell  gave  the  following  PowerPoint  presentation  on  October  27,  2003. 


Carnegie  Mellon 

Software  Engineering  Institute 


Pittsburgh,  PA  15213-3890 


Enterprise  Architecture 


Grady  Campbell 
(Robert  Seacord) 


Sponsored  by  the  U.S.  Department  of  Defense 
©  2003  by  Carnegie  Mellon  University 
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-  CarncgieMcllon 

Software  Engineering  Institute 

Enterprise  Architecture 

A  coherent  view  of  the  mission  and  capabilities  of  an 
enterprise  and  an  integrated  business/technology  strategy 
for  achieving  the  organization’s  goals 

The  set  of  rules  that  guide  all  system  development, 
modernization,  and  system  integration  efforts,  aligned  with 
enterprise  strategic  business  goals. 

•  Description  of  supported  business  processes 

•  Description  of  common  services 

•  Description  of  legacy  migration  path 

•  Prescribed  technologies  and  usage  guidelines 

•  Guidelines  for  development  of  system  architectures 

•  Patterns  (blueprints)  for  implementation  of  applications 
that  use  the  common  services  and  prescribed 
technologies 


©  2003  by  Carnegie  Mellon  University 
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Carnegie  Mellon 

Software  Engineering  Institute 


A  Simplified  Model  of  Enterprise 
Architecture 


©  2003  by  Carnegie  Mellon  University 
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-  CamegieMellon 

Software  Engineering  Institute 

Realistic  Model  for  Enterprise 
Architecture 


©  2003  by  Carnegie  Mellon  University 
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-  Carnegie  Mellon 

Software  Engineering  Institute 

Enterprise  Architecture  Elements 

Business  Goals 

Business 

•  Customer  needs 

•  Objectives/goals/strategies 

•  Organization 

•  Information 

•  Processes 

Technology 

•  Requirements 

•  Infrastructure 

•  Data 

•  Processes/Architecture 

•  Applications 

Guidelines 

©  2003  by  Carnegie  Mellon  University  page  5 
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Carnegie  Mellon 

Software  Engineering  Institute 

Business  Architecture 


Business  goals  and  core 
competencies 

Business  processes 

Organizational  structure 


©  2003  by  Carnegie  Mellon  University 
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Guidelines 
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Carnegie  Mel  Ion 

Software  Engineering  Institute 


Data  Architecture 

Enterprise  business 

information/data  needs, 

supported  by: 

•  Database  distribution 

•  Data  mining 

•  Data  protocols  for 
integration  and 
exchange 

•  Data  integrity  and 
security 

•  Data  usage 

•  Data  migration 
(optional) 


©  2003  by  Carnegie  Mellon  University 


Business  Goals 


Guidelines 
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Carnegie  Mellon 

Software  Engineering  Institute 


Information  Technology 
Architecture 


Hardware  and  software, 
the  technological  base  for 
the  enterprise  (e.g., 
GCSS-AF) 

•  Server  configurations 

•  Client  configurations 

•  Network  configuration 

•  Middleware 

•  Devices  (storage, 
printing,  etc.) 

•  Development 
environments 


©  2003  by  Carnegie  Mellon  University 


Business  Goals 
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s=.  Carnegie  Mellon 

Software  Engineering  Institute 

Application  Architecture 


Blueprints  for  the 
construction  of 
applications,  based  on  the 
IT  technologies  and 
business  data  to  support 
business  processes. 


Business  Goals 


©  2003  by  Carnegie  Mellon  University 
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Appendix  H:  Software  Sustainment  and 

Modernizing  Legacy  Systems 


Dan  Plakosh  gave  the  following  PowerPoint  presentation  on  October  27,  2003. 


Pittsburgh,  PA  15213-3890 


Software  Sustainment 


Sponsored  by  the  U.S.  Department  of  Defense 
©  2003  by  Carnegie  Mellon  University 
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Software  Sustainment* 

There  will  always  be  old  software 

The  term  “software  sustainment”  is  not  well-defined.  It  has  some  use 
within  DoD  and  limited  use  in  academia  and  industry. 

JAC/SEI  Definition  (from  Challenge  Problems)1 

“implies  integrated  logistic  support,  which  includes  all  aspects  of 
acquisition  after  initial  system  delivery  including,  e.g.,  maintenance, 
evolution,  upgrades,  warranties,  and  depot  management” 

DoD  definition2 

“involves  a  full  spectrum  of  support,  ranging  from  acquisition  and 
outsourcing,  to  in-house  development  and  modification  (with  little 
maintenance)  of  software” 


'Generally  refers  to  activities  and  techniques  used  to  maintain  software 
after  it  has  been  developed 

1  Software  Engineering  Thrusts  and  Challenge  Problems 

2  Lt.  Col.  Joe  Jarzombek,  U.S.  Air  Force  ESIP  Director,  Realities  of  Software  Sustainment  vs.  Maintenance  CrossTalk,  May  1997 

©  2003  by  Carnegie  Mellon  University  page  2 


Top  DoD  Software  Sustainment  Issues1 


Staffing:  Software  engineering  staff  instability  or  shortages 


Computer  Resources  and  System  /  Software  Engineering  Environment 
(S/SEE)  Capability:  Obsolete  and/or  saturated  computer  hardware; 
adequacy  and  long-term  viability  of  the  support  /  test  environment, 
programming  language,  etc. 


Training:  Lack  of  appropriate  and  timely  training 


Documentation:  Inadequate  or  outdated  system/software  documentation 


Guidance:  Lack  of  policy,  guidance,  and  methods  for  SIWS  acquisition 
and  support 


'AF  CIO  directed  study  “Weapon  System  Software  Sustainment  Study”,  Apr  2001 
SIWS-  Software  Intensive  Weapon  Systems 

©  2003  by  Carnegie  Mellon  University  page  3 
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Software  Evolution  and  Maintenance 
Why  is  this  important? 

Software  Lifetime  and  Maintenance  Cost 

•  Average  lifetime  of  software  is  about  10  years1 

•  Most  of  the  lifecycle  costs  for  software  occur 
after  initial  system  delivery2 

Maintenance  now  represents  over  70%  of 
the  total  cost 


'T.  Tamai  and  Y.  Torimitsu,  “Software  Lifetime  and  its  Evolution  Process  over  Generations”,  Proceedings  of  1992 
Conference  on  Software  Maintenance,  Nov.  1992. 

2R.  Grady,  Software  Metrics:  Establishing  a  Company-Wide  Program,  Prentice-Hall,  1987. 
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Software  Maintenance  Statistics1 

It  is  estimated  that  US  Corporations  spend  over  $30  billion 
annually  on  software  maintenance,  and  in  the  1990’s, 
95%  of  lifecycle  cost  would  go  to  maintenance.1 


Cashman  and  H 


Year  Maintenance  (%) 


Maintenance  Costs  as  a  %of  Total  Software  Lifecycle 
Costs 


The  Percentage  of  Software  lifecycle  costs  devoted  to  maintenance 


’Gartner  Group 

2Arthur,  L.  J.  Software  Evolution:  The  Software  Maintenance  Challenge.  John  Wiley  &  Sons,  New  York, 

1988. 

3Moad  J.  Maintaining  The  Competitive  Edge.  DATAMATION  61  -6.  1 990 
©  2003  by  Carnegie  Mellon  University  page  5 
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Software  Maintenance  Statistics2 

Over  75%  of  maintenance  costs  are  for  providing 
enhancements  in  the  form  of  adaptive  and  perfective 
maintenance. 


Maintenance 

Category 

Lientz  & 
Swanson 
1980 

Ball 

1987 

Deklava 

1990 

1990 

Corrective 

22% 

17% 

16% 

21% 

Non-Corrective 

78% 

83% 

84% 

79% 

%  effort  spent  on  Corrective  and  Non-Corrective  maintenance 


Distribution  of  maintenance  by  categories 


’Leintz  &  Swanson  1980  Lientz  B.  P.  &  Swanson  E.  B.  Software  Maintenance  Management.  Addison-Wesley  Publishing  Company.  Reading, 
Massachusetts.  1 980 

2Martin  J.  and  McClure  C.  Software  Maintenance:  The  Problems  and  Its  Solutions.  Englewood  Cliff,  NJ:  Prentice  Hall 
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Software  Maintenance  Statistics3 

Software  maintenance  consumes  the  biggest  part  of  the 
budget  devoted  to  software 


Avg. 

Information  system 

Real  time  software 

Development 

n 

n 

n 

Maintenance 

5  X  n 

3  X  n 

7  X  n 

Corrective  Maintenance 

7,5  Xn 

5  X  n 

12  X  n 

Adaptive  Maintenance 

5  X  n 

2  X  n 

5  X  n 

Perfective  Maintenance 

4  X  n 

3  X  n 

5  X  n 

Evolutive  Maintenance 

3  X  n 

2  X  n 

7  X  n 

Cost  of  developing  vs.  maintaining 
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Some  Reasons  for  Software 
Decay 


Brittle  architectures 
Requirements  changes 
Inadequate  documentation 
Loss  of  staff 

Technological  change 

•  operating  system 

•  language 

•  changes  in  supporting  software 

•  methods  and  paradigms  (e.g.,  structured  to  object  oriented) 

•  tools 


©  2003  by  Carnegie  Mellon  University 


Building  Software  for  Sustainment 

General  guidelines  (that  everybody  knows,  but  few 
practice): 

•  Build  it  right  the  first  time 

•  Move  to  the  left 

•  Develop  a  robust  architecture 

•  Design  for  change 

•  Have  strong  separation  of  concerns 

•  Document  the  knowledge  and  rationale  for  design  and 
changes 

•  Have  a  disciplined  process,  methods,  and  tools 


©  2003  by  Carnegie  Mellon  University 
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Software  Sustainment  -  How  can 
we  help  ? 


Area 

Activity 

Pre  Software  Development  - 
Acquisition  Phase 

Provide  RFP  language  (sections 

L&M)  and  evaluation  criteria  that  can 
help  increase  the  sustainability  of  the 
software  to  be  developed 

Software  Development 

Phase  -  Prior  to  transition  to 
sustainment 

Develop  policies  and  processes  that 
will  help  increase  the  sustainability  of 
the  software  once  it  is  transitioned. 

During  Sustainment 

•  Develop  policies  and  processes  that 
will  help  keep  the  system 
sustainable  through  out  its  lifecycle. 

•  Apply  some  of  our  research  work  in 
sustainment  and  transition,  if 
suitable 

©  2003  by  Carnegie  Mellon  University  page  10 


Pittsburgh,  PA  15213-3890 


Modernizing  Legacy  Systems 


Sponsored  by  the  U.S.  Department  of  Defense 
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Modernizing  Legacy  Systems, 

A  Legacy  System  can  be  defined  as  “any  system  that 
significantly  resists  modification  and  evolution.”  [Brodie  95] 

They  can  cause  several  problems 

•  Usually  run  on  obsolete  hardware  that  is  slow  and 
expensive  to  maintain. 

•  Software  maintenance  can  also  be  expensive,  because 
documentation  and  understanding  of  system  details  is 
often  lacking  and  tracing  faults  is  costly  and  time 
consuming. 

•  A  lack  of  clean  interfaces  makes  integrating  with  other 
systems  difficult. 

•  Often  are  difficult,  if  not  impossible,  to  extend. 


©  2003  by  Carnegie  Mellon  University 


Modernizing  Legacy  Systems,, 


Modernization  involves  extensive  changes,  but  conserves  a 
significant  portion  of  the  existing  system. 


For 

example: 


Modernize  From 

To 

Batch  sequential 
architecture 

B2B/component- 
based  architecture 

Hierarchical/network 
structure  database 

Relational  structure 

Mainframe  platform 

J2EE-based  platform 

COBOL/Fortran 

Java 
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mBfc'i'ssait 


Software  Evolution 


Time 


2003  by  Carnegie  Mellon  University 


Legacy  Crisis  i 

The  amount  of  legacy 
code  is  immense  and 
growing. 

•  250  billion  lines  of 
source  code  being 
maintained 
[Sommerville  00]. 
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Legacy  Crisis  2 

Information  systems  expand  with  time 
•  The  average  Fortune  100  company  [Muller  94] 

-  maintains  35  million  lines  of  code 

-  adds  10%  per  year  in  updates,  enhancements,  and 
other  maintenance. 

-  code  doubles  in  size  every  seven  years 

Cumulative  code  changes  over  many  years  often  lead  to 
less  maintainable  code. 

Increased  complexity  means  that  the  system  becomes 
increasingly  brittle. 


©  2003  by  Carnegie  Mellon  University 


Modernization  Challenges 

Legacy  system  size  and  complexity 
Conflicting  stakeholder  priorities 
Software  technology  and  engineering  processes 
Achieving  business  objectives 
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Modernizing  Legacy  Systems  - 
How  can  we  help  ? 

•  Provide  training  and  coaching  with  respect  to 
modernizing  legacy  systems 

-  Address  the  Legacy  Modernization  Challenges 

-  Establish  good  modernization  strategies 

•  Direct  support  and  consultation 

-  Design  and  architecture  reviews 

-  Determine  technical  quality  and  business  value  of 
candidate  software 

-  Development  and  execution  of  tailored 
modernization  strategies 
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Appendix  I:  Capability  Maturity  Model  - 
Integrated  (CMMI) 


Kristi  Keeler  gave  the  following  PowerPoint  presentation  on  October  27,  2003. 


_  CarnegieMellon 

Software  Engineering  Institute  cmmi 

Pittsburgh,  PA  15213-3890 
Arlington,  VA.  22203 

CMMI®  -  The  Next  Step  in 
Process  Improvement 

SSG  Presentation  10-27-2003 


Kristi  Keeler 


SM  SCAMPI,  SCAMPI  Lead  Appraiser,  and  SEI  are  service  marks  of  Carnegie  Mellon  University. 

®  CMMI,  Capability  Maturity  Model,  and  CMM  are  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon 
University. 

Sponsored  by  the  U.S.  Department  of  Defense 
©  2003  by  Carnegie  Mellon  University 
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CarnegieMellon 

Software  Engineering  Institute  cmmi 

This  Presentation 

Provides  an  overview  of  CMMI 

The  Past — where  we’ve  been  and  what  has  influenced  us 
The  Present — where  we  are 

The  Future — where  we  are  going  and  how  you  can  help 
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Software  Engineering  Institute  cmmi 

The  Past 

era  of  “manufacturing  in  quality” 

The  premise  of  “manufacturing  in  quality” 

•  Implies  a  focus  on  processes  as  well  as  on  products 

•  Is  a  long-established  premise  in  manufacturing 

•  Is  based  on  Total  Quality  Management  principles  as 
taught  by  Shewhart,  Juran,  Deming,  and  Humphrey 

“It  costs  a  lot  of  money  to  build  bad  products.” 

Augustine’s  12th  Law 

“The  quality  of  a  system  is  highly  influenced  by  the 
quality  of  the  process  used  to  acquire,  develop,  and 
maintain  it.” 

Phillip  Crosby  “Quality  is  Free:  The  Art  of  Making  Quality  Certain” 
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Carnegie  Mellon 

Software  Engineering  Institute 


CMMI 


Quality  Management  Maturity  Grid 


Management 

Categories 

Stage  1 : 

Uncertainty 

Stage  2: 

Awakening 

Stage  3: 

Enlightenment 

Stage  4: 

Wisdom 

Stage  5: 

Certainty 

Cost  of 
quality  as  % 
of  sales 

Reported: 
unknown 
Actual:  20% 

Reported: 

5% 

Actual:  18% 

Reported:  8% 
Actual:  12% 

Reported: 

6.5% 

Actual:  8% 

Reported: 

2.5% 

Actual:  2.5% 

Summation 
of  company 
quality 
posture 

"We  don't 
know  why 
we  have 
quality 
problems.” 

"Must  we 
always  have 
quality 
problems?" 

'We  are 
identifying  and 
resolving  our 
quality 
problems." 

'We 

routinely 

prevent 

defects 

from 

occurring." 

'We  know 
why  we  don't 
have  quality 
problems." 

Crosby,  P.  Quality  is  Free:  The  Art  of  Making  Quality  Certain.  New  York:  McGraw- 
Hill,  1979. 
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The  Present 

era  of  “engineering  in  quality” 

CMMs®  focus  on 

•  Process  and  product  quality 

•  Business  results 

•  Engineering  in  quality 

CMMs  continue  to  be  adopted  and  used 

Companies  in  key  markets  are  adopting  CMMs 

•  Defense 

•  Aerospace 

•  Automotive 

•  Entertainment 

•  Telecommunications 

•  Finance 
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Multiple  Process  Models 


Success  of  the  Software 
CMM®  caused  development 
of  other  CMMs,  but  they 

•  Have  different  structures, 
formats,  terms,  ways  of 
measuring  maturity 

•  Cause  confusion, 
especially  when  more  than 
one  are  used 

•  Are  difficult  to  integrate 
into  a  combined 
improvement  program 

•  Are  difficult  to  use  in 
supplier  selection 
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CMM 


People 

CMM 


Systems 
Security 
Engr  CMM 


Software 

Acq 

CMM 


EIA  731 


Carnegie  Mel  Ion 

Software  Engineering  Institute  cmmi 

Sunsetting  of  SW-CMM 

Introduction  to  SW-CMM  training  course 

•  Last  public  offering  from  SEISM  is  December  2003 

•  Continued  availability  from  transition  partners 

CBA-IPI  Assessments  and  SCE  Evaluations 

•  Last  Lead  Assessor  (LA)  training  is  December  2003 

•  Last  Lead  Evaluator  (LE)  training  is  October  2003 

•  LA  and  LE  authorizations  expire  December  31,  2005; 
Las  and  Les  must  upgrade  to  SCAMPISM  to  continue 
providing  SEI-Authorized  appraisal  services 

For  more  information,  see  the  Sunset  FAQ  at 
http://www.sei.cmu.edu/cmmi/adoption/sunset-faq.html 
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The  Future 

era  of  “innovating  in  quality” 

We  face  unprecedented  engineering  challenges. 

Customer  demand  quality  products  faster  and  cheaper. 
Management  expects  higher  productivity. 

Engineering  fields  continually  evolve  and  merge. 
Organizations  are  dynamic;  there  is  much  more  partnering. 
Our  knowledge  and  experience  must  be  shared. 

The  future  is  now! 

CMMI  is  our  knowledge  infrastructure 
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CMMI  Is  Integration  and 
Improvement 

CMMI  supports  process  integration  and  product 
improvement. 

CMMI  integrates  multiple  disciplines  into  one  process- 
improvement  framework  that  eliminates  inconsistencies 
and  reduces  duplication. 

CMMI  provides  a  framework  for  introducing  new 
disciplines  as  needs  arise  and  therefore  reduces  the  cost 
of  implementing  model-based  improvement. 

CMMI  is  designed  to  minimize  the  impact  on  legacy 
process  improvement  efforts  and  investment. 
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CMMI  Models 


Source  Models 


•  Capability  Maturity  Model® 
for  Software  V2,  draft  C 
(SW-CMM  V2C) 

•  EIA  731 ,  System 
Engineering  Capability 
Model  (SECM) 

•  Integrated  Product 
Development  Capability 
Maturity  Model,  draft 
VO. 98  (IPD-CMM) 


CMMI 

-Meets  the  needs  of 
software  organizations 

-  Is  an  upgrade  of  SW-CMM 

-  Benefits  from  best 
practices  contributed  from 
all  three  source  models 
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Improving  on  the  Software  CMM 

CMMI  Models  improve  on  SW-CMM  Version  2.0  Draft  C: 

•  Incorporate  additional  years  of  learning 

•  More  explicitly  link  best  practices  to  business  objectives 

•  Expand  the  scope  of  and  visibility  into  the  product  life 
cycle  and  engineering  activities 

•  Add  more  best  practices,  (e.g.,  measurement,  risk 
management,  product  integration,  decision  analysis  and 
resolution,  and  supplier  management) 

•  Capture  more  robust  high-maturity  practices 

•  Address  additional  generic  practices  needed  for 
institutionalization 

•  More  fully  comply  with  relevant  ISO  standards 
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One  Model,  Two  Representations 


|  Appendixes 


Maturity  Level  5 
OID,  CAR 


Maturity  Level  4 
OPP,  QPM 


Maturity  Level  3 

REQD,  TS,  PI,  VER, 
VAL,  OPF,  OPD,  OT, 
IPM  RSKM  PAR 


Maturity  Level  2 
REQM,  PP,  PMC, 
SAM,  MA,  PPQA,  CM 


jr 


Overview 
Introduction 
Structure  of  the  Model 
Model  Terminology 

Maturity  Levels,  Common  Features,  and  Generic  Practices 
Understanding  the  Model 
Using  the  Model 


CMMI-SE/SW 

Staged 
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Support 

CM,  PPQA,  MA, 
- CAR,  PAR - 


Engineering 

REQM,  REQD,  TS, 
PI.  VER.  VAL 


Project  Management 
PP,  PMC,  SAM 
IPM,  RSKM,  QPM 


jr 


Process  Management 
OPF,  OPD,  OT, 
OPP,  OID 


iZL 


Overview 
Introduction 
Structure  of  the  Model 
Model  Terminology 

Capability  Levels  and  Generic  Model  Components 
Understanding  the  Model 
Using  the  Model 


CMMI-SE/SW 

Continuous 


_  Carnegie  Mellon 

Software  Engineering  Institute  cmmi 

Understanding  CMMI 
Representations 

A  representation  allows  an  organization  to  pursue  different 
improvement  objectives  and  presents  model  components 
differently.  The  content  is  nearly  identical  in  both 
representations. 

So  why  both? 

•  The  representation  of  each  source  model  was  different 

-  Software  CMM — Staged 

-  SE-CMM,  SECM — Continuous 

•  Ease  adoption  by  legacy  communities. 

•  Both  representations  provide  inherent  benefits. 
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Advantages  of  Each 
Representation 


CMMI 


Continuous  Representation 

Staged  Representation 

Provides  maximum  flexibility  for 
order  of  process  improvement 

Predefined  and  proven  path  with 
case  study  and  ROI  data 

High  visibility  of  improvement  within 
process  areas 

Focuses  on  organizational 
improvement 

Easy  upgrade  from  EIA  731 

Easy  upgrade  from  SW-CMM 

Easy  comparison  to  ISO  15504 

Provides  familiar  benchmarking 
capability 

Improvement  of  process  areas  can 
occur  at  different  rates 

Overall  results  summarized  in  a 
maturity  level 
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CMMI  in  a  Nutshell 

A  CMMI  model  provides  a  structured  view  of  process 
improvement  across  an  organization. 

CMMI  can  help 

•  set  process  improvement  goals  and  priorities 

•  provide  guidance  for  quality  processes 

•  provide  a  yardstick  for  appraising  current  practices 
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CMMI  Today 

Stable  Version  1.1  CMMI  Product  Suite  was  released 
January  2002 

CMMI  models  will  not  change  until  2005  at  earliest  (per 
CMMI  Steering  Group  direction) 

Many  defense,  aerospace,  and  commercial  organizations 
are  upgrading  to  CMMI 

One  appraisal  method,  SCAMPI,  covers 

•  internal  process  improvement 

•  supplier  source  selection 

•  contract  process  monitoring 
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Early  Adopters 


CMMI 


Currently  there  are  30+  early 
adopters. 

Are  you  an  early  adopter? 

Send  email  to  cmmi- 
comments@sei.cmu.edu  to  be 
listed. 

See  Early  Adopter  list  at 
http://www.sei.cmu.edU/cmmi/a 

doption/earlv-adopters.html 


Communlcatons 

Transraon 


o  Product  Suite 


The  Boeing  Company 

fll  Brown 

World  Wide  Web:  hfla/AwM.boeina.com 


o  Proiecl  Groups 
o  Oman  King 
Documents 


Harris  Corporation 

Oary  Natwick,  Senior  Principal  Engineer 
E-mail:  anatwcki3harri5.com 
World  WideWeb:  hiMwM.liairis.com 

JacobsISverdrup  Technology  Inc.,  Advanced  Systems  Group 
Engineering  Performance  Improvement  Center  (EPIC) 

Jeffrey  L.  Dutton,  Technical  Director 
E-mail:  duttohiiaBverdmii.com 


CMMI 


U.S.  Army  TACOM-ARDEC  Software  Enterprise 

S.  Wayne  Sherer,  Senior  Technical  Associate  toi  Corporate  Process  Improvement 
E-mail:  wsherer0pica.army.mil 


Ityou  have  questions  or  comments,  send  email  to  modi 
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Discoveries  in  Use 

Ease  of  upgrade  to  CMMI  reported  by: 

•  Multiple  SW-CMM  level  5  organizations  that  upgraded  and 
maintained  their  maturity  level 

•  Multiple  organizations  that  upgraded  from  EIA  731  systems 
engineering  assessments 

•  Numerous  European  companies  in  group  discussion  of  CMMI 
adoption  at  recent  SEI-Europe  quarterly  meeting 

Appraisal  times  reflect  excellent  learning  curves 

•  Australian  group  reported  40%  reduction  in  appraisal  time  as 
learning  occurred  over  five  appraisals 

Mappings  and  gap  analyses  confirm  evolutionary  expansion  from 

predecessor  models 

•  Government  and  contractors  agree  on  CMMI’s  improved 
engineering  coverage  in  contract  monitoring 

•  ISO/CMMI  compatibility  appears  favorable 
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Where  We’re  Going 

Adoption  activities 

•  Transition  Partner  data 

•  Workshops,  technical  notes,  and  book  publication 

•  Interpretive  Guidance  project 

Appraisal  enhancement  activities 

•  SCAMPI  appraisal  data 

•  CMMI  appraisals  conducted  worldwide 

•  SCAMPI  enhancements 

Training  activities 

•  CMMI  training  data 

•  Training  course  upgrades 
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Adoption — What’s  Happening 
Now 


Events  related  to  CMMI  adoption: 

•  Quarterly  transition  workshops 

•  Annual  NDIA/SEI  CMMI  User  Workshop 
Interpretive  Guidance  project 
Technical  notes  and  special  reports: 

•  CMMI  and  Product  Line  Practices 

•  CMMI  and  Earned  Value  Management 

•  Interpreting  CMMI  for  Operational 
Organizations 

•  Interpreting  CMMI  for  Service 
Organizations  (in  progress) 

•  CMMI  Mappings 

•  Specific  interests  (e.g.,  safety,  security) 
Publication  of  SEI  Series  Book  with 
Addison-Wesley 


Mary  Beth  Chrissis 
Mike  Konrad 
Sandy  Shrum 
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In  Summary 

In  today’s  fast-paced,  competitive  business  environment, 
approaches  used  in  the  past  such  as  “manufacturing  in 
quality”  and  present,  “engineering  in  quality”  are  not 
enough.  The  future  is  innovation. 

CMMI  helps  organizations  to  ... 

•  Improve  delivery  of  performance,  cost,  and  schedule 

•  Integrate  stakeholders  into  project  activities 

•  Provide  competitive  world-class  products  and  services 

•  Implement  an  integrated  enterprise  business  and 
engineering  perspective 

•  Use  common,  integrated,  and  improving  processes  for 
systems  and  software 

Upgrade  to  CMMI  now...  and  lead  the  way  to  the  future  of 
process  improvement. 
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For  More  Information... 

For  more  information  about  CMMI,  see 
http://www.sei.cmu.edu/cmmi/ 

You  can  find  more  presentations  like  this  on  the  SEI  Web 
site  at  http://io.sei.cmu.edU/pub/enqlish.cqi/0/323123. 


Or,  contact 

SEI  Customer  Relations 

Phone:  41 2/ 268-5800 

Email:  customer-relations@sei.cmu.edu 


©  2003  by  Carnegie  Mellon  University 


96 


CMU/SEI-2004-SR-003 


CMU/SEI-2004-SR-003 


97 


Appendix  J:  COTS-Based  Systems 


John  Foreman  gave  the  following  PowerPoint  presentation  on  October  27,  2003. 


Carnegie  Mel  Ion 

Software  Engineering  Institute 


Pittsburgh,  PA  15213-3890 


COTS-Based  Systems 


Sponsored  by  the  U.S.  Department  of  Defense 
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COTS:  Attraction  and  Motivation 


legacy  systems 
evolution 


MVORE 


demands 
for  new 
systems  and 
functionality 


.  dinger  Cohen/ITMRA 

.Technology  insertion 

acquisition 
reform 


Develop  faster 
Reduce  cycle  time 
Leverage  commercial  investment 
&  economies  of  scale 
Leverage  new  technology 
•  Lower  (life  cycle)  costs 


\u 


COTS! 


M 

ff 

BUD 

GET 

c/>e, 


Revised  FARS/DFARS, 
5000.1, 5000.2-R 
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COTS  Challenges 


•  Limited  visibility  into  product 
quality  and  behavior 

•  Varying  architectural  paradigms 

•  Dependencies  between  products 

•  Built-in  models  of  use 

•  New  “business”  issues  (licenses, 
data  rights,  warranties) 


•  Products  driven  by  market, 
not  your  system  context 

-  Frequent  product  and 
marketplace  changes 

-  Limited  control  of  content 
or  frequency  of  releases 

*  Vendor  differentiation 
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Fundamental  Change 


Traditional  Approach 
(Waterfall  Development) 


System 

Context 


Architecture  & 
Design 


Implementation 


Build  from  Scratch 


Required  COTS  Approach 


requirements 

cost 

schedule 
business 
processes 
operational 
procedures,  etc. 


•  COTS  products 
■  NDI 

•  standards 


Strongly 
influenced  by 
products 


Buy,  Integrate,  Continuously  Refresh 
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Cyclic  Nature  of  COTS-Based  Systems 


•  Demand 
for 

features 


.Marketplace 


System 

Context 

Simultaneous 
Definition 
and  Tradeoffs 


Incremental 
system  releases 


c 

RIP 

w 


mi . 


Architecture 
&  Design 


•  Unsupported  releases 
'  No  market  demand 


l— > 


■  System 
development 

■  Tech  refresh, 
system  sustainment 
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CBS  are  Radically  Different 


Mil  Spec 


COTS 


•  Requirements  driven 
•Spec  Focus 

•  Rigid  requirements 

•  Unique  architecture 
•Owner  controls  evolution 
•Stable  design 

•  Ignore  evolution 
•Cost  emphasis 

•  Make  custom  hardware 

•  Develop  software 
•Obsolescence 
•Waterfall-style  development 
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•Market  driven 
•Business  plan  focus 
•Flexible  requirements 
•Open  system  architecture 
•Market  controls  evolution 
•Constant  changes 
•Design  forevolution  (tech  refresh) 
•TOC  emphasis 
•Buy  from  catalog 

•  License  software 

•  Earlier  obsolescence 
•Spiral  development 
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CBS  Implications  for  You 

New  requirements  processes  -  more  flexible 

New  concerns  over  existing  end-user  processes  -  Acquisition 
and  development  processes  as  well  as  Business/end  user 
processes  must  yield  to  the  realities  of  commercial  practice 

More  use  of  spiral/iterative/incremental  approaches 

Different  view  of  system  sustainment/CM 

New  questions  about  COTS  products  and 
reliability/safety,  performance/real-time 
security/survivability 

New  skill  sets  required 
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CBS  Capabilities  and  Products 

•COTS  Product  Evaluation  Techniques 

-  Determining  the  right  product  in  the  right  context 

•Design  and  Engineering  Practices 

-Techniques  for  analysis  of  alternatives,  design, 
integration,  and  sustainment 

•COTS  Based  Process  Framework 

-  Develop  /  Institutionalize  new  management  and 
development  processes  to  build,  field,  and  support  CBS 

•Risk  Identification  and  Mitigation 

-  Identify  and  propose  mitigations  for  comr 
CBS  risks  and  known  failure  modes 

-  COTS  Usage  Risk  Evaluation  (CURE) 

•Information  Dissemination 

-Technical  publications,  Courses/tutorials 
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Why  is  COTS  Product  Evaluation 
Hard? 

COTS  product  evaluation  is  the  examination  of  individual 
COTS  products  for  the  purpose  of  determining  the 
products’  fitness  for  use  in  a  particular  context. 


Less  than  perfect  system 
understanding 


Conflicting  interests 
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Design  and  Engineering  Practices 

Techniques  that  facilitate  analysis  of  alternatives, 
design,  integration,  sustainment,  and  evolution  of 
COTS  Based  Systems: 

•  Developing  “just-in-time”  competency 

•  Component  ensemble  evaluation  that  focus  on 
project  risk  rather  than  product  features 

•  Capturing,  representing  and  sharing  component 
integration  knowledge 

•  Legacy  system  modernization 


Black  box  products 
and  vendors 


Rapid  rate  of  change 
of  COTS  products 
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Model 

Problems 


Architect  Evaluate 

[sustained]  JL  [falsified] 


What:  Model  Problems 
are  prototypes  where 
the  consumer  is  the 
designer. 

Why: 

•  Spot  technical  risks 

•  Quickly  develop 
know-how  on  how  to 
resolve  risks 
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Evolutionary  Process  for  Integrating 
COTS-Based  Systems  (EPIC) 

EPIC  operationalizes  software  engineering  best  practice 
and  COTS  lessons  learned  to  build,  field,  and  support 
COTS-based  systems 

•  Negotiation-driven,  disciplined,  spiral  approach 

•  Objectives,  activities,  and  artifacts  at  a  sufficient  level  of 
detail  to  facilitate  needed  culture  change  (using  RUP  for 
basic  management  and  engineering  processes  and 
artifacts) 
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COTS  Based  Process  Framework 
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EPIC  Concepts 


Knowledge  grows  incrementally 

•  Risk-based  spiral  development 

•  Frequent,  evolving  executable 
representations  show  understanding 

Decisions  converge  iteratively 

•  Trades  are  negotiation-driven 

•  Requirements  formed  based  on 
knowledge  of  market/architecture 

•  Continuous  awareness  of  changes 
to  end-user  business  processes 


Stakeholder  buv-in  increases 

Stakeholder  needs  mature 
Quick  resolution  to  mismatches 
Business  processes  change  to 
leverage  available  products 
End  users  committed  to  solution 
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Phases  Bounded  by  Anchor  Points 


LifeCycle 

Objectives 


LifeCycle 

Architecture 


Initial 

Operational 

Capability 


■  ■  ■  MK 


V _ /#'  V. _ V _ '*  \ — ^ - '#  v - '#  k- - '* 

Multiple  iterations  (Plan,  (Gather,  Refine),  Assemble,  Assess)  per  phase 
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COTS  Usage  Risk  Evaluation  (CURE) 


•What:  Early  identification  of  COTS-based  risks  within  a 
program  to  raise  management  awareness 
•Who:  Focus  is  comprehensive: 

•  integrators  and  developers 

•  acquirers  and  managers  [_ 

•Result:  Report  on  risks  and  mitigations 

•  Preferred:  out-brief  delivered  to  program  management 

•  Optional:  written  report  impact 


I 


Typical  time 
that  “red 
teams"  are 


Minimum 
impact  *  Pre-award  •  Contract 

program  planning,  award  team 

•  Source  selection  building 

•  Proposal  •  Establish 

development  risk  baseline 


Program 

midpoint 


TIME 
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COTS-Based  Systems  Courses 


Audience 

Offerings 

•  Executives  (govt  and  industry) 

•  OSD  policy  makers 

•  PEOs,  DACs,  CIOs,  CFOs 

•  COTS-Based  Systems  (CBS)  for 
Executives  (2.5  hrs) 

•  Open  Systems  for  Executives  (4.5  hrs) 

•  Program  managers  (PMs) 

•  Functional  managers 

•  Financial/budget  personnel . . . 

•  CBS  for  PMs  (4-5  hrs) 

•  CBS  for  PMs  -  on  CDROM  ffY 

•  CBS  for  PMs  w/  extended 

discussion  (8  hrs)  2/ 

•  CBS  Workshop  for  PMs  (8  hrs) 

•  Technical  staff  -  engineers, 
system  integrators,  proposal 
evaluators,  contracts  personnel 

•  COTS  Product  Evaluation  (abridged  -  3 
hours,  full  -  2  days) 

•  Building  Systems  from  Commercial 
Components  (abridged  -  4  hrs,  2  Days) 

•  Modernizing  Legacy  Systems  (8  hrs) 

•  CBS  for  Practitioners  -  2  Days 

©  2003  by  Carnegie  Mellon  University 
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Appendix  K:  The  Mind  Maps 


The  mind  maps  in  this  appendix  were  created  on  October  27,  2003  as  outputs  from  mapping 
SEI  technologies  to  various  SSG  strategic  objectives. 
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Figure  2:  Map  of  SEI  Technologies  Against  SSG  (Cluster  Focused  on  Customer 
Issues) 
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Appendix  L:  COTS-Based  Systems 

Enablers  and  Barriers 


The  list  of  COTS-Based  Systems  Enablers  and  Barriers  was  created  as  workshop  output  on 
Tuesday,  October  28,  2003. 

CBS  Barriers  &  Enablers  -  Engineering  &  Integration 

CBS  Barriers 

1 .  Individual  skills/skill  sets 

Erosion  of  talent  when  we  can’t  “offload”  benched  team  members 

2.  Lack  of  palpable  experience,  success  with  integration 

3.  Current  processes/procedures  are  “engrained”  in  workforce  /  unwillingness  to  change 

4.  Competing  org  (MSG)  appears  to  be  “better  positioned”  to  do  this. 

(Not  necessarily  better  equipped.) 

5.  Undefined,  detailed  standard  configurations  for  AF. 

No  one  accountable  to  adopt  standards 
Insufficient  motivation  to  comply 

6.  Customers  are  “finding”  and  dictating  “solutions” 

CBS  Enablers 

SEI  can  train/mentor  on  CBS  intelligence 

1 .  Change  in  AF  personnel  system 
Training  and  workforce  reshaping 
Shift  focus  to  external  sources 

2.  Partnering  with  proven  winners  in  industry 
Locally  fielded  solutions 

Do  “pilot”  programs  small  scale 

3.  OSD  “enterprise  integration  toolkit” 

“First  fielding”  of  20%  EPIC  solution  pilots 
Decision-makers  must  control  at  least  some  resources 
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4.  (+1)  Use  current  resident  expertise  to  explore  new  possibilities  and  look  forward 
Improve  working  relationship  with  HQ  AFMC 

Hire  an  ERP  advisor  to  SSG/ED 

5.  Define  what  “standards”  are  -  many  kinds 
Focus  on  results  and  capability  of  STDs 

Gap  Analysis 

•  Gap  Analysis:  what  you  have,  what  is  available,  what  you  need 

•  Staffing 

•  Communication/coordination 

•  Work  environment 

•  *  Performance  management:  implementation  by  managers  &  DAG/DP,  Pilot  =  Ml 

•  *  Training/development:  mapping  training  to  needs  (#’s) 

•  Compensation 
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Appendix  M:  People  Capability  Maturity 

Model  Enablers  and  Barriers 


This  outline  of  enablers  and  barriers  was  output  of  the  P-CMM  pilot  planning  session  (part  of 
the  workshop  held  on  Tuesday,  October  28,  2003). 

1.  Goal: 

•  processes  &  practices  for  Level  2 

•  process  areas  piloted  and  ready  for  organizational  implementation  by  12/04 

2.  Picture  of  success: 

•  SSG  workforce  mgmt  practices  support  transformation  objectives  and  speed 
transformation  of  organization  to  be  Center  of  Excellence  for  AF  combat  support  IT 

3.  Success  Criteria: 

•  Practices  implemented  by  75%  of  2-ltr  orgs.  at  SSG 

•  Customers  recognize  increased/new  capabilities  of  SSG  and  select  SSG  for  work 

4.  Tasks  (Next  3  months): 

•  Gap  analysis  of  SSG  workforce  practices  against  P-CMM 

•  Recommendations  for  improvement 

•  Coordination  points  for  Booz -Allen  human  capital  plan 

•  Implementation  plan  for  P-CMM  improvement 

5.  Tie  to  Balanced  Scorecard: 

•  Innovation/learning 

a.  Maintain/add  technologically  current  skills 

b.  Enhance  PM  skills  base 

c.  Develop  technological  expertise 

d.  ID  right  mix  of  skills  needed  @  SSG 
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e.  Knowledge  mgmt 

•  Internal  ops 

a.  Communication  &  coordination 

b.  Adequacy  &  modernization  of  infrastructure 

•  Customer  focus 

a.  Align  SSG  members  to  mission 

b.  Be  easy  to  do  business  with 
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Appendix  N:  Capability  Maturity  Model- 

Integrated  Enablers  and 
Barriers 


This  outline  of  enablers  and  barriers  to  the  success  of  Configuration  Maturity  Model- 
Integrated  was  output  of  the  workshop  held  on  Tuesday,  October  28,  2003. 


CMMI  Barriers  to  Success 

1 .  Lack  of  knowledge  in  writing  clear,  firm  requirements. 

2.  Responsibility  for  training?  Who  ‘owns’  this? 

3.  Need  independent  determination  of  requirements  quality  (clear,  complete,  etc.)  prior  to 
design. 

4.  Lack  of  commitment  to  process,  contract.  Tool  does  not  replace  process  and  training. 

5.  Unrealistic  expectations  from  customer. 

6.  No  customer  or  funding  for  enterprise  architecture  and  integration  requirements. 

7.  Willing  to  perform  at  risk  and  accept  unrealistic  requirements. 

8.  Inadequate  capture  of  baseline  and  senior  management  tracking  of  changes  (impact  of 
changes  on  program  success). 

9.  Government  and  contractor  disagreement  or  misunderstanding  of  roles  and 
responsibilities. 


Enablers  of  Success 

1.  SEP 

2.  DOORS  (and  its  integration  with  Mercury  Test  Director),  Rational,  Performa. 

3.  EN  for  non-functional  requirements  (e.g.:  GCSS,  DFAS,  sizing,  etc.) 

4.  Staff  responsiveness. 

5.  Combined  Test  Force  (CTF)  and  the  move  of  testing  to  requirements  phase. 
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Pilot  Ideas 

1 .  Develop  requirements  facilitation  function  with  domain  knowledge,  contract 
understanding,  and  experience.  This  should  be  an  SSG  level,  corporate  shared  resource. 
(AQ,  ST) 

2.  Identify  lead  projects  and  teams  from  each  SPO.  (not  to  exceed  6  months,  3  to  4 
projects/teams)  .=>  Revised  REQM  process.  (IL,  FN,  ST,  AQ) 

3.  Implement/improve  Earned  Value  Management  processes  with  senior  management  level 
tracking  of  significant  deviations  (5%),  =>  SEMA.  (XP) 

4.  Restart  recurring  program  review  for  senior  staff  that  includes  functional  staff.  (XP) 


CMMI  Pilot  Planning  Session 

1 .  Pilot  Goal: 

•  Establish  and  charter  a  requirements  facilitation  team  and  supporting  processes. 

•  Document  requirements  management  and  requirements  engineering  processes  beginning 
with  customer  view,  covering  complete  life  cycle  of  requirements.  Introduce  tools  and 
processes  to  customer. 

•  Develop  a  shared  view  of  the  requirements  (an  educated  customer). 


2.  Deliverables: 

•  Customer  education  process. 

•  Requirements  communication  plan. 

•  Requirements  management  documentation. 

•  Requirements  engineering  documentation. 

•  Capture  pilot  lessons. 


3.  Picture  of  success: 

•  “Better”  requirements  documentation  and  customer  has  a  better  understanding  of 
requirements. 

•  Requirements  are  “right.” 
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•  Definition  of  “better”  requirements,  “right”  (According  to  Customer,  According  to  SSG) 

4.  Success  Criteria: 

•  No  DRs  tied  to  requirements  (based  upon  root  cause  analysis  of  the  DR). 

•  Positive  CSAR  (Customer  Satisfaction  Assessment  Report). 

5.  Next  3  months: 

•  Gap  analysis  discussion. 

•  Form  IPT  (SSG,  Customer,  SEI). 

•  Develop  charter  template. 

6.  Tie  to  Balance  Scorecard: 

•  Customer  Focus:  Easy  to  do  business  with  (customer  satisfaction). 

•  Center  of  choice  (cheaper). 

7.  LOE  Estimate  for  next  3  months,  each  member  of  IPT: 

•  25  FTE  for  pilot  project,  gap  analysis. 


Notes: 

IPT  Members: 

•  Contracting/AQ 

•  FM 

•  FN  (program  manager)  -  system  view  of  requirements 

•  SEPG 

•  EN  (non  functional  requirements) 

•  ST  (software  requirements)/IL  (COTS) 
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•  Customer/functional  representation  (DFAS) 

•  XP  (tools) 

•  SEI 

The  process  must  be  iterative,  tied  to  spiral  development  and  release  processes. 
Leverage  the  current  SEP,  tools,  meetings,  historical  data. 
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